Une recette est modifiée après un essai de développement, mais le rapport ne conserve que le nom du cycle. Le processus suivant se termine sans alarme et le lot est lié à un PDF qui n'identifie pas la version utilisée. La machine a peut-être correctement exécuté sa logique, mais le lien entre les paramètres approuvés, la configuration effective et le matériel traité est absent. C'est ce lien que l'automatisation doit rendre vérifiable.
1. Définir le périmètre du système informatisé
Le système comprend bien plus que l'automate programmable (PLC). Il faut prendre en compte l'IHM, l'enregistreur indépendant, l'historien, le serveur, la base de données, la gestion des utilisateurs, la synchronisation temporelle, la sauvegarde et les interfaces avec le MES ou les systèmes qualité. Identifiez où naissent les données, où elles sont transformées et où elles sont conservées. Un diagramme des flux doit également décrire les interruptions de communication et le fonctionnement temporairement autonome.
Distinguez le contrôle du processus de la gestion documentaire. Une recette approuvée dans le système qualité ne prouve pas que les mêmes paramètres sont actifs dans le PLC. Un enregistrement correct dans le PLC ne prouve pas que l'exportation a conservé tous les événements. Les interfaces font partie de l'utilisation prévue et doivent être incluses dans l'évaluation.
[REGULATORY REQUIREMENT] L'Annexe 11 des BPF de l'UE exige une approche du cycle de vie basée sur les risques pour les systèmes informatisés utilisés dans les activités BPF. Le texte en vigueur listé par EudraLex au moment de la vérification est celui de 2011 ; les éventuelles propositions de révision ne doivent pas être présentées comme des exigences déjà applicables.
2. Transformer la stratégie de processus en états vérifiables
Décrivez la séquence comme une série d'états et de transitions : prêt, charge identifiée, conditionnement, exposition, séchage ou refroidissement, achèvement, anomalie et arrêt. Pour chaque transition, définissez les conditions nécessaires, les délais (timeout), les événements enregistrés et l'état des sorties. Le comportement doit être compréhensible sans avoir à lire le code source.
La transition vers l'exposition doit refléter la stratégie validée. Si elle dépend de plusieurs mesures, clarifiez la manière dont les valeurs manquantes ou non valides sont traitées. La perte d'un signal ne doit pas être interprétée accidentellement comme une satisfaction de la condition. Le même principe s'applique à la fin de cycle, à l'autorisation de déchargement et au passage vers une zone plus critique.
[GEP] Utilisez une matrice cause-effet pour les interverrouillages et les alarmes critiques. Documentez l'événement, la phase, l'action, l'état sûr et les conditions de rétablissement. La matrice soutient le développement, la révision et les tests, réduisant ainsi les écarts entre la spécification fonctionnelle, le programme et la procédure opératoire.
3. Gérer les recettes et les paramètres comme des configurations contrôlées
Chaque recette doit avoir une identité, une version, un état et un champ d'utilisation. Séparez les recettes de développement, de test et de production, avec des règles empêchant l'utilisation involontaire de configurations non approuvées. Définissez quels paramètres sont fixes, lesquels sont sélectionnables et lesquels sont modifiables dans des limites autorisées.
La révision doit comparer l'ancien contenu au nouveau, la motivation, l'impact et les approbations requises. L'enregistrement de cycle doit identifier la version effectivement exécutée et conserver les valeurs nécessaires pour reconstruire la séquence. Enregistrer uniquement le nom « cycle composants » ne permet pas de distinguer des configurations différentes portant la même étiquette.
Considérez le moment où la recette est chargée dans le contrôleur. Si une modification est approuvée alors qu'un cycle est déjà en cours, il doit être clair quelle version gouverne ce cycle. Les tests doivent vérifier que les mises à jour ou les synchronisations ne modifient pas silencieusement les paramètres d'une séquence active.
4. Concevoir des accès cohérents avec les responsabilités
Définissez des rôles pour l'opérateur, le superviseur, la maintenance, l'administrateur et le réviseur. Attribuez les privilèges nécessaires aux activités et distinguez l'exécution du cycle de la modification de la configuration. Évaluez la séparation des responsabilités pour les opérations critiques, en tenant compte de la structure du site et des mesures compensatoires documentées.
Les comptes doivent permettre d'attribuer les actions aux personnes autorisées. Les identifiants partagés réduisent cette capacité et nécessitent une évaluation concrète des limites du système. L'accès de service du fournisseur doit avoir un objectif, une autorisation, une durée et un enregistrement cohérents avec les procédures du site.
Testez la création, la modification, la désactivation et l'expiration des accès, en plus du login ordinaire. Vérifiez ce qui arrive à une session ouverte lorsqu'un rôle est révoqué et comment sont gérés les comptes inutilisés. Les fonctions administratives doivent être incluses dans la vérification, car elles peuvent modifier les contrôles sur lesquels repose la confiance dans les données.
5. Rendre la piste d'audit (audit trail) utile à la révision
La piste d'audit doit permettre de comprendre qui a exécuté une action, quand, sur quel élément et avec quel résultat. Pour les modifications importantes, conservez les valeurs précédentes et suivantes, ainsi que la motivation lorsque celle-ci est requise. La configuration du traçage doit être protégée et vérifiée pour les fonctions pouvant influencer le processus ou les enregistrements.
Toutes les entrées n'ont pas la même signification. Une modification de recette, la désactivation d'une alarme, un changement d'heure et une tentative d'accès infructueuse soutiennent des évaluations différentes. Définissez quels événements sont réexaminés par cycle, lesquels périodiquement et lesquels nécessitent une intervention immédiate. La fréquence doit être motivée par le risque et l'utilisation.
Une fonction d'exportation doit maintenir l'ordre, l'identité et le contexte des entrées. Vérifiez les filtres, la pagination et les plages temporelles pour éviter qu'une impression apparemment complète n'omette des événements. Conservez également la possibilité de récupérer les données originales : une capture d'écran ne remplace pas l'enregistrement électronique.
6. Lier les alarmes, les abandons et les redémarrages
Un abandon (abort) interrompt ou met la séquence en sécurité selon une logique définie. Le redémarrage peut entraîner une reprise, une nouvelle séquence ou une interdiction de continuation, selon le processus. Ces comportements doivent être établis lors du développement et validés ; ils ne peuvent dépendre uniquement de la préférence de l'opérateur au moment de la panne.
Définissez quels événements rendent la performance du cycle non démontrable, même s'ils ne provoquent pas de dommage mécanique. La perte de données critiques, une erreur de recette ou le non-respect d'une condition peuvent nécessiter une gestion différente d'un simple avertissement. Le message final doit représenter correctement l'état et ne pas effacer l'historique précédent.
Au redémarrage après une coupure de courant, le système doit reconnaître l'état du cycle interrompu et rendre disponibles les informations conservées. Les tests doivent évaluer les différents moments de la séquence. Un redémarrage réussi du PLC démontre une disponibilité technique, pas la conformité de la charge présente durant l'interruption.
7. Définir l'enregistrement original et les copies
Établissez quelles données constituent l'enregistrement nécessaire à la décision BPF et où elles résident. Incluez l'identification de la charge, la version de la recette, les valeurs réelles, les événements, les métadonnées et les approbations pertinentes. Si l'enregistrement est distribué, documentez les liens et les responsabilités de conservation.
Un PDF peut être une copie utile pour la révision, mais il faut prouver qu'il conserve les informations nécessaires à l'utilisation prévue. Les données dynamiques, la piste d'audit ou les détails non exportés peuvent nécessiter la disponibilité du système original ou d'une archive adéquate. Le choix doit être justifié, et non basé uniquement sur la facilité d'impression.
Vérifiez l'exhaustivité et l'exactitude des transferts vers l'historien ou le MES. Prenez en compte les doublons, les retards, les enregistrements hors ordre et la perte temporaire du réseau. Les règles de réconciliation doivent rendre les problèmes visibles, en empêchant qu'un rapport ne soit déclaré complet lorsqu'une partie des données est manquante.
8. Matrice des tests essentiels
| Fonction | Scénario à vérifier | Preuve attendue |
|---|---|---|
| Recette | Modification approuvée avant et pendant un cycle | Version appliquée sans équivoque et contrôlée |
| Accès | Utilisateur sans privilège tente une modification critique | Action empêchée et traçage pertinent |
| Alarme | Perte d'une mesure critique en exposition | Réponse, résultat et données conformes aux spécifications |
| Communication | Interruption entre PLC et système d'enregistrement | Lacune détectée et récupération réconciliée |
| Sauvegarde | Restauration sur configuration autorisée | Données lisibles, intègres et utilisables |
| Horloge | Changement autorisé ou perte de synchronisation | Séquence temporelle reconstructible |
Les scénarios sont une base opérationnelle [GUIDEGXP RECOMMENDATION], non une liste normative exhaustive. Le plan doit inclure les risques spécifiques du système et des critères définis avant l'exécution. Un test satisfaisant doit démontrer le comportement requis, et pas seulement l'absence d'un message d'erreur.
9. Sauvegarde, restauration et continuité opérationnelle
La sauvegarde doit comprendre les données et configurations nécessaires à la récupération. Identifiez les recettes, programmes, paramètres, utilisateurs, certificats et composants pertinents selon l'architecture. Protégez les copies et vérifiez que le processus fonctionne. La présence d'un fichier dans le dossier de destination ne prouve pas que la restauration est possible.
Les tests de restauration doivent montrer que le système récupéré est utilisable et que les enregistrements restent complets et lisibles. Définissez les conditions d'exécution du test pour éviter tout effet sur la production. Documentez la version, l'environnement, les données échantillons et le résultat, avec une évaluation des limites du test.
La continuité opérationnelle doit clarifier la marche à suivre lorsque le système électronique n'est pas disponible. Une procédure manuelle temporaire n'est acceptable que si elle est prévue, adéquate et capable de préserver les contrôles nécessaires. N'introduisez pas d'enregistrements rétroactifs dépourvus de preuves pour combler une perte de données.
10. Exemple : rapport complet, données incomplètes
Dans un cas illustratif, le PDF indique le résultat positif du PLC, tandis que l'historien a perdu la connexion durant une phase critique. La reconstruction montre que le contrôleur possède certaines données locales, mais le système d'impression ne signale pas la lacune. L'équipe suspend l'acceptation automatique et évalue la disponibilité des preuves originales.
L'enquête distingue la performance physique de l'exhaustivité de l'enregistrement et vérifie si les données locales permettent une reconstruction fiable. La correction comprend le signalement des transferts incomplets et une procédure de réconciliation. Les tests ultérieurs incluent la perte de connexion, la récupération et la prévention des doublons.
La leçon opérationnelle est que le format du rapport ne doit pas créer une apparence d'exhaustivité supérieure aux données disponibles. Le résultat final doit expliciter l'état de l'enregistrement et les exceptions. Le système qualité décide du matériel sur la base des preuves effectives, et non de la mise en page du document.
11. Validation et gestion du fournisseur
Évaluez la compétence, les processus de développement, la gestion des versions et le support du fournisseur. La documentation et les tests du fabricant peuvent contribuer à la vérification, s'ils sont adéquats et réexaminés. La responsabilité du site pour l'utilisation BPF n'est pas transférée par l'achat d'un progiciel dénommé « validé ».
[GUIDANCE] GAMP 5, deuxième édition de 2022, offre un cadre de bonnes pratiques pour les systèmes informatisés. Ce n'est ni une norme de loi ni une certification automatique du logiciel. Le niveau de preuve doit être proportionné au risque, à l'utilisation prévue et à la connaissance du système.
Liez l'URS, les spécifications, l'évaluation des risques, les tests et les déviations. Définissez les critères de mise en service et les responsabilités pour le maintien de l'état validé. Une liste de tests effectués ne suffit pas si l'on ne sait pas quels requis elle couvre et quels risques restent ouverts.
12. Changements, obsolescence et révision périodique
Les mises à jour logicielles, les correctifs, les remplacements matériels, les migrations et les modifications des interfaces peuvent influencer le contrôle ou les données. Le contrôle des changements (change control) doit évaluer l'impact, les tests nécessaires, le plan de restauration et la mise à jour de la documentation. La définition d'« équivalent » doit être soutenue par des caractéristiques pertinentes, et pas seulement par le modèle commercial.
La révision périodique prend en compte les incidents, les accès, les performances, les sauvegardes, les modifications, la documentation et le support. Évaluez également les dépendances externes et les composants qui ne sont plus supportés. Planifiez le rétrofit avant qu'un remplacement urgent ne force des décisions prises sans preuves suffisantes.
Les principaux signaux d'alerte (red flags) sont : comptes partagés sans contrôle, recettes sans version, piste d'audit non révisable, sauvegardes jamais restaurées et rapports masquant des lacunes. Une bonne automatisation rend visible la relation entre la configuration approuvée, les actions des utilisateurs, le processus exécuté et les données conservées.
13. Critères de livraison à la production
Avant la mise en service, vérifiez que la configuration installée coïncide avec celle testée et que les recettes de production sont approuvées. Confirmez la disponibilité des procédures, la formation des utilisateurs, la gestion des anomalies et les responsabilités administratives. Les déviations ouvertes doivent faire l'objet d'une évaluation documentaire de l'impact et d'une décision autorisée, en évitant qu'une liste d'activités résiduelles ne masque des fonctions critiques non démontrées.
Livrez une base de référence récupérable (baseline) du logiciel et des configurations, avec des références aux versions et aux tests. Le site doit savoir comment obtenir de l'assistance et quelles interventions du fournisseur nécessitent une autorisation préalable. Établissez également comment vérifier l'absence de modifications inattendues après un accès distant ou une intervention de maintenance.
Un transfert de responsabilité efficace comprend une démonstration opérationnelle avec les utilisateurs : sélection de la charge, démarrage, lecture de l'enregistrement, gestion d'une exception et récupération des données archivées. La capacité à effectuer ces activités confirme que le système est utilisable conformément aux procédures. Cela ne remplace pas la validation, mais peut mettre en évidence des lacunes organisationnelles avant l'utilisation productive.
Références et parcours
Sources vérifiées le 23 septembre 2026 : EU GMP Annexe 11, version en vigueur listée, et Annexe 15 ; ISPE GAMP 5, deuxième édition 2022, catalogue officiel. Les matrices de cet article sont originales et ne reproduisent pas de procédures propriétaires.
Approfondissez Sterilization & Depyrogenation Systems, monitorage des cycles, qualification des stérilisateurs et Automation & Digital Systems.
