Un enregistrement SCADA indique une modification de consigne, mais utilise un compte partagé, une heure locale répétée lors du changement saisonnier et aucune référence à la recette active. La valeur existe ; la preuve reste ambiguë. L’intégrité des données dès la conception traite ces faiblesses dans l’acquisition, les actions, les interfaces et les enregistrements conservés.
L’objectif pratique est de préserver des informations fiables pendant leur cycle de vie. Cet article porte sur les décisions d’ingénierie de l’automatisation, sans reproduire un guide général CSV ou Annexe 11 : que faut-il capturer, protéger, comprendre et reconstituer en fonctionnement normal comme en situation dégradée ?
Cartographier les données autour des décisions réelles
Identifier les informations utilisées pour contrôler le procédé, revoir la production, investiguer les écarts et décider du devenir du produit. Suivre création, traitement, transfert, revue, conservation et suppression. Inclure services intermédiaires, exports manuels et feuilles de calcul lorsqu’ils appartiennent au workflow réel. Le périmètre de la seule application principale peut masquer des transformations importantes.
Pour chaque décision, déterminer données originales et métadonnées nécessaires. Une mesure peut nécessiter unité, source, qualité et contexte temporel. Un changement de recette peut exiger identité, valeurs ancienne et nouvelle, motif et version. Un calcul demande les entrées et la logique permettant de comprendre son résultat selon l’usage et les exigences applicables.
[GUIDANCE] FDA, PIC/S et MHRA décrivent des informations attribuables, lisibles, contemporaines, originales, exactes, complètes, cohérentes, durables et disponibles. Ces principes ALCOA+ orientent l’évaluation ; les afficher dans un document ne démontre pas leur respect par les workflows configurés.
Identifier les originaux et les métadonnées nécessaires
Déterminer où l’information devient un enregistrement et quelles transformations suivent. Valeur affichée, observation stockée et rapport imprimé ne contiennent pas nécessairement la même information. Un export statique peut omettre des relations dynamiques nécessaires. Définir si une copie préserve contenu et signification pour son utilisation.
La responsabilité des enregistrements détermine le système conservant la preuve de référence. Si elle est distribuée entre contrôleur, historian et MES, définir relations stables et responsabilités de restitution. Un lien ouvrant la tendance actuelle par défaut est moins robuste qu’une référence contrôlée à l’équipement, la période et au contexte voulus.
La configuration participe à l’interprétation : échelle, unités, affectation de point, calcul et version de recette influencent les valeurs. Conserver les historiques ou références nécessaires. Réutiliser un identifiant pour un autre capteur sans documenter la transition peut rendre les anciennes observations trompeuses malgré des nombres inchangés.
Concevoir les pistes d’audit des changements significatifs
Identifier créations, modifications et suppressions nécessitant un historique protégé selon le cadre et l’usage. Définir contenu, protection, revue et restitution. Un journal technique peut enregistrer les redémarrages sans conserver les valeurs avant et après un changement de recette. Évaluer la piste d’audit selon sa fonction réelle.
Examiner tous les chemins d’action : écran opérateur, outil d’ingénierie, API, administration de base et import de configuration. Une interface protégée ne suffit pas si un autre chemin autorisé modifie les preuves sans contrôle équivalent. Fermer les chemins inutiles et surveiller les privilèges nécessaires.
La configuration d’audit elle-même doit être contrôlée. Qui peut l’activer, la désactiver ou la modifier ? Comment détecter ces actions et une panne de stockage ? Une case « audit activé » ne garantit pas la couverture. Tester modifications représentatives, tentatives refusées et consultation de l’historique produit.
Séparer événements, alarmes et preuves d’audit
Les événements décrivent des occurrences ; les alarmes sollicitent une réponse ; l’audit permet de reconstituer actions et modifications pertinentes. Une occurrence peut figurer dans plusieurs journaux aux objectifs différents. Acquitter une alarme ne prouve pas sa résolution ; un journal de connexion n’explique pas nécessairement une modification procédé.
Définir les corrélations grâce aux identifiants d’équipement, lot, utilisateur et aux temps. Une investigation ne doit pas reposer sur des suppositions. Préserver le contexte lors des exports tout en contrôlant les copies et les accès selon leur utilisation.
[RECOMMANDATION GUIDEGXP] Prévoir un exercice d’investigation pendant la conception. Demander à un réviseur d’expliquer une modification connue avec les seules preuves disponibles. Si l’explication dépend de la mémoire du développeur, corriger les informations manquantes avant mise en service.
Traiter le temps comme une dépendance commune
Définir sources approuvées et acquisition du temps par contrôleurs, serveurs, postes et services. NTP ou un autre mécanisme soutient la cohérence, mais configuration, connectivité et détection des défaillances restent nécessaires. Prévoir perte de synchronisation et détection des dérives selon le besoin évalué.
Distinguer heure source, collecte et traitement. Une observation récupérée après interruption conserve l’heure de l’événement nécessaire à l’interprétation ; elle ne doit pas apparaître comme une mesure nouvelle. Lorsque plusieurs temps sont conservés, identifier clairement leur signification.
Maîtriser fuseaux et transitions saisonnières. Conserver assez de contexte pour distinguer deux heures locales identiques. Examiner les corrections d’horloge sur séquences, calculs et certificats. Déduire les limites des besoins procédé et documentaires, sans inventer une dérive maximale ou fréquence universelle GMP.
Rendre les accès attribuables et proportionnés
Définir rôles de production, supervision, maintenance, ingénierie, administration et revue. Affecter les droits selon fonctions et séparations nécessaires. L’attribution individuelle est essentielle pour les actions devant être identifiées. Les comptes humains partagés la fragilisent, sauf dispositif justifié et contrôlé préservant cette attribution par d’autres moyens fiables.
Gérer séparément les comptes de service : propriétaire, but, fonctions et cycle des identifiants. Empêcher l’utilisation habituelle de comptes privilégiés de maintenance par commodité. Contrôler création, modification et suppression, notamment départs de personnel et accès fournisseurs.
Concevoir un accès d’urgence utilisable : autorisation, durée, surveillance et revue ultérieure, en considérant l’indisponibilité du service d’identité. Des règles impraticables favorisent les contournements. Sessions et authentification sont justifiées pour le système ; elles ne proviennent pas de nombres présentés comme universels.
Préserver le sens dans interfaces et calculs
L’intégrité peut être perdue sans malveillance : conversion erronée, doublon, identifiant tronqué ou mesure invalide interprétée comme valable. Définir la sémantique et vérifier la transaction complète. Un canal chiffré protège l’échange, sans démontrer que le destinataire comprend correctement son contenu.
Contrôler calculs et résultats dérivés. Conserver population d’entrée, version et traitement des absences ou exclusions nécessaires à la reconstruction. Tester exemples connus et limites. Un rapport ignorant silencieusement des lacunes peut produire un résultat plausible à partir d’un dossier incomplet.
L’article intégration des systèmes GMP traite doublons, confirmations et rapprochement. Les exigences d’intégrité doivent apparaître dans le contrat d’interface et les preuves d’acceptation, pas uniquement dans une politique générale.
Distinguer sauvegarde, archive et suppression contrôlée
Une sauvegarde soutient la reprise après perte ; une archive soutient l’accès pendant une durée définie. Identifier données, configurations, métadonnées et dépendances pour chacune. Une sauvegarde de base dépourvue de configuration applicative ou de clés peut ne pas restaurer un enregistrement interprétable.
Déduire la conservation des obligations et de la politique approuvée. Coordonner les suppressions entre systèmes afin de préserver observations et audit nécessaires aux dossiers encore utilisés. Restreindre les droits et conserver les preuves de destruction autorisée lorsque requis. Dimensionner le stockage selon population et croissance réaliste.
Tester restauration et restitution d’archives avec dossiers représentatifs et anciennes versions. Vérifier contenu, relations, droits et compréhension. Un statut de sauvegarde réussi ne prouve pas une restauration. Voir l’architecture MES et historian pour les enregistrements distribués.
Faire de la revue une capacité opérationnelle
Définir qui examine quelles informations, pourquoi et avec quelle escalade. Périmètre et moment dépendent des dossiers, risques et exigences. Ne pas annoncer une fréquence universelle de revue des pistes d’audit. La revue doit détecter les problèmes significatifs sans produire une masse inexploitable d’entrées indifférenciées.
Fournir recherche et filtres préservant le contexte. Vérifier règles et complétude des rapports d’exception. Distinguer « aucun événement pertinent » de « données indisponibles » ou « recherche non exécutée ». Conserver décisions et liens vers les investigations des constats non résolus.
Former les réviseurs au sens technique : commande refusée, action exécutée, changement de configuration ou observation ancienne récupérée. Le système doit soutenir ces distinctions avec des informations claires, sans exiger une interprétation technique non documentée.
Construire des preuves d’acceptation ciblées
| Enjeu | Épreuve | Preuve recherchée |
|---|---|---|
| Attribution | Deux utilisateurs réalisent des changements distincts | Identité et contexte corrects dans un historique protégé |
| Temps | Récupération de données tamponnées | Heure originale distincte de la réception |
| Couverture d’audit | Modification par un autre chemin permis | Historique requis équivalent ou chemin interdit |
| Complétude | Acquisition ou stockage audit indisponible | Détection, réponse et limitation visible |
| Conservation | Consultation après changement de configuration | Valeurs, métadonnées et contexte interprétables |
Choisir les essais selon fonctions et modes de défaillance évalués. Conserver identité de configuration et observations réelles. Un certificat fournisseur générique ou une démonstration de connexion réussie ne démontre pas l’intégrité complète des données du système.
Exemple : ajustement de recette pendant une suspension
Un procédé illustratif autorise un superviseur à modifier un paramètre dans des bornes approuvées pendant une suspension. La conception initiale conserve uniquement la valeur finale dans le rapport. Elle ne distingue pas valeur initiale et ajustement, ni la personne responsable.
La conception corrigée conserve version de recette, valeurs ancienne et nouvelle, identité autorisée, heure, motif et lot. Elle montre la modification en attente avant acceptation et conserve le résultat réel du contrôleur. Une perte de communication ne doit pas être présentée comme une réussite avant confirmation définie.
L’acceptation comprend modification permise, valeur hors limites, utilisateur non autorisé et échange interrompu. Le réviseur reconstitue chaque résultat à partir des preuves. Ces contrôles découlent de l’usage du procédé et n’impliquent pas un workflow d’approbation identique pour tous les paramètres.
Traiter les limites des équipements anciens et des fournisseurs
Les équipements autonomes peuvent limiter identité, audit ou export. Évaluer ces limites face aux actions et dossiers requis. Une supervision moderne ne répare pas automatiquement un défaut local : l’historian central ne reconstitue pas une modification non enregistrée en collectant seulement sa conséquence mesurée.
Identifier des mesures compensatoires pratiques, documentées et proportionnées, puis juger leur adéquation. Certaines limites exigent modification technique ou remplacement. Attribuer responsable et plan de cycle de vie pour éviter que des pratiques manuelles temporaires deviennent permanentes sans réévaluation.
Les services gérés par fournisseur nécessitent responsabilités claires pour accès, configuration, conservation, incidents et restitution. Confirmer la récupération des dossiers et de leur contexte en cas de fin de service. Une propriété contractuelle des données n’est utile qu’avec une méthode d’extraction et de lecture démontrée sur des dossiers représentatifs.
Vérifier aussi les outils d’administration et les exports périodiques. Un compte privilégié peut modifier une table sans passer par l’écran contrôlé ; un export peut supprimer unités ou indicateurs de qualité. Définir les accès nécessaires, les preuves disponibles et la revue correspondante, puis démontrer leur fonctionnement dans le périmètre réellement autorisé.
Pour les limitations acceptées, décrire précisément les informations absentes, leur conséquence sur la décision et la mesure compensatoire. Une mention générale « système legacy » ne constitue pas une justification. La responsabilité de réévaluation doit rester identifiable lorsque l’usage, le risque ou le support change.
Vérifier que les personnes chargées de la revue disposent des droits nécessaires pour consulter ces preuves, sans recevoir pour autant les privilèges permettant de les modifier. La consultation et l’administration répondent à des responsabilités différentes.
Statut réglementaire et responsabilité dans le temps
[EXIGENCE RÉGLEMENTAIRE] Appliquer les exigences pertinentes au système configuré. Au 23 septembre 2026, Annexe 11 et Chapitre 4 opératoires restent les textes de 2011 ; les propositions de 2025 restent des projets. Le périmètre Part 11 dépend des enregistrements, signatures et exigences sous-jacentes. Les guidances ne sont pas interchangeables avec la législation.
[BONNES PRATIQUES D’INGÉNIERIE] Maintenir les contrôles pendant changements, incidents et retrait. Réévaluer les dossiers affectés par acquisition, identités, interfaces ou rapports. Relier cette démarche aux Environmental Monitoring Systems et au hub Automation & Digital Systems.
Sources primaires
Vérification au 23 septembre 2026 : EudraLex Volume 4 ; 21 CFR Part 11 ; guidance FDA finale, décembre 2018 ; PIC/S PI 041-1, juillet 2021 ; guidance MHRA GxP, mars 2018. La note ultérieure de priorité OCDE concerne les GLP ; elle ne retire pas globalement la guidance GMP.
