Un skid peut réussir sa démonstration en usine et rester inadapté au site de fabrication. Le contrôleur exécute la séquence, mais une interruption du réseau laisse le dossier de lot incomplet ; un opérateur modifie un paramètre sans motif traçable ; un serveur de remplacement ne restaure pas la recette approuvée. Ces défauts concernent les exigences avant de devenir des constats de validation. La spécification des exigences utilisateur, ou URS, doit décrire le résultat attendu, les conditions de fiabilité et les preuves nécessaires à son acceptation.
Cet article traite de l'URS d'ingénierie des PLC, DCS, SCADA, historiens, MES et interfaces. Il aide les équipes procédé, production, automatisation, qualité et IT/OT à convenir des fonctions nécessaires avant que le fournisseur ne fixe la conception. L'architecture et la stratégie de validation restent adaptées à l'utilisation prévue du site.
Définir l'utilisation prévue et les limites du système
Décrire les familles de produits, étapes, modes opératoires et décisions soutenues. Un contrôleur régulant la température d'une cuve n'a pas la même utilisation qu'un historien servant à examiner une excursion, même si tous deux traitent la même mesure. Préciser si une fonction contrôle le procédé, informe un opérateur, crée un enregistrement requis, autorise une activité ou transmet une information. Ces finalités déterminent les contrôles et les preuves.
Séparer limites physiques et logiques. Les premières comprennent instruments, entrées-sorties, contrôleurs, postes, serveurs, réseau et infrastructure. Les secondes couvrent recettes, calculs, droits, interfaces, transformations et responsabilités. Un service d'identité externe peut être exclu du contrat tout en restant une dépendance du système qualifié. Identifier explicitement qui le fournit, le configure, le vérifie et le maintient.
Attribuer également un responsable aux exclusions. « Intégration MES exclue » ne suffit pas si le skid dépend d'une réponse MES pour terminer une opération. Définir le fonctionnement autorisé avant cette interface et les conditions de son introduction ultérieure.
Distinguer besoin utilisateur et choix de conception
Une exigence doit exprimer le résultat nécessaire sans transformer une préférence non examinée en obligation. « Utiliser des serveurs redondants » désigne une solution. « Maintenir les fonctions de supervision définies lors de la défaillance identifiée d'un serveur, en préservant les enregistrements confirmés » décrit un résultat analysable. La redondance peut convenir, mais son périmètre, son basculement et ses défaillances résiduelles doivent être justifiés.
Certaines contraintes sont légitimes : plateforme supportée, réseau approuvé, protocole existant ou compétences de maintenance. Les identifier comme telles et expliquer leur origine. Séparer obligations, préférences et options futures. Sinon, des fonctions souhaitables peuvent absorber l'attention tandis qu'une dépendance critique reste dissimulée dans le texte.
Attribuer à chaque exigence un identifiant stable, un propriétaire et une méthode d'acceptation. Éviter de réunir accès, sauvegarde, signature et alarmes dans une phrase acceptée par une seule réponse « conforme » sans preuve.
Décrire les fonctions de contrôle et les anomalies
Préciser variables, sorties, plages, états et transitions. L'URS ne doit pas reproduire tout le programme PLC, mais doit expliquer démarrage, pause, maintien, arrêt, abandon, reprise et fin. Définir disponibilité des équipements et réconciliation des opérations interrompues. Indiquer qui peut demander chaque transition et quelles conditions doivent être confirmées avant exécution.
Distinguer permissif, interverrouillage et alarme : autoriser une action, la bloquer ou la modifier, et demander une réponse opérateur sont des fonctions différentes. Une alarme n'est pas automatiquement une protection. Une confirmation HMI ne prouve pas davantage le mouvement d'une vanne. Pour les commandes critiques, définir retour d'état, discordance et preuve du résultat réel.
Concevoir explicitement modes manuels et dégradés, protections conservées, restrictions et mesures complémentaires. Le passage systématique en manuel après perte de communication est une hypothèse insuffisante : la réponse dépend de l'état, de l'équipement et des dangers. Examiner séparément alimentation, qualité des signaux, communications et services de support.
Attribuer recettes, paramètres et approbations
Séparer recette maître approuvée et recette de contrôle instanciée pour un lot. Une formule fournit des valeurs, mais ne représente pas nécessairement toute la recette, qui comprend aussi procédure et exigences d'équipement. Définir où chaque élément est rédigé, approuvé, transféré et exécuté. MES peut coordonner le flux tandis que le contrôleur exécute les phases, avec une répartition explicite.
Définir plages autorisées, droits de modification, version applicable et traitement des lots en cours. Prévoir une recette incomplète, incompatible ou antérieure à la version approuvée. Préciser les cas de nouvelle approbation, nouvelle instance ou exception documentée. Les valeurs proviennent du procédé et de la stratégie approuvée, pas des réglages par défaut du fournisseur.
Pour les applications CIP et SIP, distinguer exécution du cycle et démonstration de ses critères d'acceptation. Une séquence terminée ne prouve pas à elle seule l'efficacité du nettoyage ou de la stérilisation.
Identifier les enregistrements avant le stockage
Créer un inventaire reliant chaque classe de données à son usage et à son responsable : mesures originales, qualité, temps, unités, lot, versions, actions, exceptions, calculs et décisions. Une valeur affichée peut être transitoire. Un enregistrement GMP nécessite le contexte permettant de reconstituer l'activité. Définir la source faisant autorité et l'identification des copies.
Spécifier acquisition et compression selon les événements à résoudre. Une exécution rapide du contrôleur ne garantit pas une résolution historique équivalente. Examiner si collecte, agrégation ou bande morte peuvent masquer une excursion brève ou une transition. Définir traitement des valeurs absentes, retardées, invalides et récupérées. Éviter tout intervalle universel de collecte ou de conservation.
Distinguer piste d'audit, journal d'événements et journal d'alarmes. Identifier modifications et suppressions pertinentes, identité, chronologie, motif lorsque requis, accès de revue et export. « Piste d'audit activée » ne démontre pas la couverture des approbations, configurations ou activités privilégiées.
Rendre les interfaces responsables de la transaction
Pour chaque échange, documenter propriétaires, identifiants, sens des champs, unités, versions, horodatages et états. Un accusé réseau peut confirmer une livraison sans confirmer l'acceptation d'une consommation, d'une instruction ou d'un résultat. Définir confirmation applicative et réponse lorsqu'elle manque ou indique un rejet.
Concevoir ensemble répétitions et doublons. Après rupture, l'émetteur peut ignorer si son premier message a été appliqué. Une répétition sans identité stable peut doubler une quantité ou déclencher une opération indésirable. Définir détection des omissions, doublons et états contradictoires, avec autorisation de résolution. Vérifier la reprise sur tout le parcours équipement–supervision–exécution.
OPC UA, API et middleware sont des moyens techniques, pas des preuves de justesse sémantique. Définir contrat de données et sécurité indépendamment d'une simple déclaration de compatibilité avec un protocole standard.
Construire une matrice exigences–preuves
Les exemples originaux suivants illustrent la structure. Remplacer conditions et détails d'acceptation par ceux du procédé approuvé et de son évaluation des risques.
| Exigence | Justification | Impact GMP | Risque | Critère d'acceptation | Vérification | Preuve |
|---|---|---|---|---|---|---|
| Exécuter la recette approuvée | Éviter des paramètres involontaires | Constance du procédé | Version obsolète exécutée | Seule une version approuvée admissible démarre ; la version exécutée reste liée au lot | Essayer versions approuvées, obsolètes et incompatibles | Configuration, exécution et résultats des exceptions |
| Conserver l'identité lors d'une répétition | Éviter une double application | Généalogie des matières et lots | Quantité modifiée deux fois | Livraison répétée avec un seul effet prévu ; conflits visibles | Interrompre la réponse après enregistrement chez le destinataire | Journaux des deux systèmes et réconciliation |
| Récupérer le dossier défini | Permettre la reconstitution | Revue et conservation | Métadonnées absentes après restauration | Ensemble approuvé produisant des enregistrements lisibles, complets et correctement associés | Restaurer dans l'environnement autorisé | Journal de reprise, comparaison et acceptation |
La matrice n'est utile que si elle renvoie à des preuves réelles. Distinguer revue, inspection, analyse et essais. Expliquer la couverture lorsqu'un test soutient plusieurs exigences au lieu de multiplier les scripts identiques. Maintenir visibles les lacunes jusqu'à la décision de mise en service.
Spécifier accès, chronologie et sécurité OT
Définir les rôles selon les tâches : conduite, rédaction et approbation des recettes, maintenance, administration et revue. Identifier droits incompatibles et accès d'urgence. L'accès distant du fournisseur nécessite demande, autorisation, connexion, supervision appropriée, enregistrement et fermeture. Un intégrateur privilégié ne relève pas du même modèle qu'un opérateur courant.
Décrire source de temps, dépendances de synchronisation, fuseaux et comportement en cas de perte. Distinguer occurrence et réception, en conservant cette distinction pendant mise en mémoire et retransmission. Les horodatages doivent rester interprétables pour reconstruire la chronologie GMP.
Utiliser inventaire et risque OT pour définir segmentation, communications, configuration sûre, évaluation des correctifs et reprise. Les protections IT doivent tenir compte du procédé. À l'inverse, le statut validé ne justifie pas une vulnérabilité laissée sans gestion.
Définir disponibilité, reprise et transfert à l'exploitation
La disponibilité concerne la continuité ; la reprise concerne la restauration après perturbation. Le matériel redondant ne démontre pas automatiquement les deux. Identifier alimentation, stockage, authentification et réseau partagés. Définir si chaque perte permet de continuer, impose un maintien contrôlé ou exige un arrêt.
Séparer sauvegarde, archive et reprise après sinistre. La sauvegarde permet la restauration ; l'archive préserve l'accès pendant la durée requise ; la reprise coordonne applications, infrastructure, données, personnes et redémarrage. Déduire délais et pertes admissibles du procédé et de la continuité. Inclure configuration, certificats, licences, recettes et dépendances.
Exiger un transfert maintenable : sources et configurations approuvées, outils, responsabilités du support, versions supportées, obsolescence, pièces et modifications. Définir les preuves de restauration et de mise à niveau avant le départ de l'équipe projet.
Prévoir une assurance proportionnée
[EXIGENCE RÉGLEMENTAIRE] Pour les activités EU GMP concernées, l'Annexe 11 relie exigences utilisateur, impact GMP, risque documenté et traçabilité. L'Annexe 15 traite qualification et validation. Traduire ces obligations en preuves pertinentes plutôt qu'en nombre prédéterminé de documents. Les textes applicables restent distincts des projets de consultation de 2025, selon la vérification du 23 septembre 2026.
[GUIDE] GAMP 5, deuxième édition, soutient une démarche fondée sur le risque. Le guide FDA CSA final de février 2026 concerne la production et les systèmes qualité des dispositifs médicaux ; il ne remplace pas universellement la CSV pharmaceutique. [NORME] ASTM E2500-25 fournit un cadre scientifique de vérification. Motiver les méthodes sans présenter les guides volontaires comme une législation.
[RECOMMANDATION GUIDEGXP] Convenir avant l'achat des preuves fournisseur réutilisables, de leurs conditions d'acceptation et des vérifications propres au site. FAT peut démontrer des fonctions configurées ; SAT l'installation et les interfaces. Leur intitulé ne suffit pas à établir la qualification. La décision finale identifie configuration, défauts résolus, risques résiduels, responsables formés et traitement des actions ouvertes.
Examiner l'URS avec une défaillance réaliste
Considérer une cuve batch dont le contrôleur continue pendant la perte de l'historien. La production demande de la continuité, la qualité des preuves complètes et IT une répétition automatique. Suivre l'interruption de la mesure à la revue : mémoire tampon, surveillance de capacité, conservation du temps et de la qualité, saturation et réconciliation.
Le résultat utile est un ensemble d'exigences et de scénarios liés. « Aucune perte de données » laisse la conception ouverte. Déterminer si arrêt, poursuite avec enregistrements alternatifs approuvés ou maintien dans un état défini sont justifiés. La décision appartient au site, sur la base du procédé et du risque, avec contribution du fournisseur.
- Chaque exigence critique répond-elle à un besoin de fabrication ou d'enregistrement ?
- Modes normaux, anormaux, manuels et de reprise sont-ils définis ?
- Les interfaces confirment-elles la transaction attendue ?
- Le site peut-il obtenir, revoir, restaurer et conserver les preuves ?
- Responsabilités, acceptation et support sont-ils sans ambiguïté ?
Les domaines décisionnels Automation & Digital Systems développent architecture et assurance. L'URS peut être approuvée lorsque l'équipe explique le résultat requis et la manière de démontrer qu'il est atteint.
Avant de figer la spécification, faire examiner les exigences par les personnes qui exploiteront et maintiendront le système. Vérifier qu'une exclusion contractuelle ne laisse pas une fonction essentielle sans responsable et qu'une hypothèse technique possède une condition de confirmation. Conserver les décisions et les points ouverts avec leur propriétaire. Cette revue permet de transformer l'URS en base commune de conception, d'achat et d'acceptation, plutôt qu'en document interprété différemment par chaque discipline.
Références et statut
- Commission européenne, EudraLex Volume 4 : Annexe 11, chapitre 4 et Annexe 15 applicables.
- Consultation européenne 2025 : projets distincts des exigences actuelles.
- ISPE GAMP 5, deuxième édition, juillet 2022 : guide professionnel.
- FDA CSA, février 2026 : final, périmètre dispositifs médicaux.
- ASTM E2500-25 : norme active, périmètre éditeur vérifié.
- NIST SP 800-82r3 : guide OT final ; révision 4 encore en projet.
