Guide Validation Informatique

ALS GAL GUI 084 00 #
Page : 1 / 38
[468614552.doc]
[]
TITRE : PRINCIPES DE LA VALIDATION D'UN SYSTÈME

D'INFORMATION
Rédacteur : Hervé CLUZEAUD Visa :
Vérificateur : Guillaume CARDON Visa :
Vérificateur AQ : Hélène LAROUMANIE Visa :
Émetteur : Pierre GÉRUS Visa :
Date Émission :
Évolution du document :
Révision 00 Établissement du document
A : Ajouter - M : Modifier - S : Supprimer
Améliorations / Corrections à retourner au secrétariat du Groupe Support Technique

Tel : 01 41 02 81 57 - Fax : 01 49 07 00 15
Sommaire :
1. OBJET.......................................................................................................................................................................3
2. DOMAINE D’APPLICATION............................................................................................................................3
3. DOCUMENTS DE RÉFÉRENCE........................................................................................................................3
3.1. Les textes réglementaires.......................................................................................................................3
3.2. Les guides d’application........................................................................................................................4
4. PRÉSENTATION GÉNÉRALE...........................................................................................................................4
4.1. Historique.................................................................................................................................................4
4.2. Contraintes réglementaires....................................................................................................................5
4.3. Maîtrise du projet....................................................................................................................................6
4.3.1. Les activités de projet..........................................................................................................................6
4.3.2. Le processus de qualification/validation........................................................................................9
4.4. Principes généraux................................................................................................................................11
4.4.1. Phases de conception........................................................................................................................11
4.4.2. Phases d’essais....................................................................................................................................13
4.4.3. Acteurs.................................................................................................................................................15
4.4.4. Analyse de risques.............................................................................................................................15
4.4.5. Activités supports..............................................................................................................................16
4.4.6. Synthèse : la stratégie de validation...............................................................................................17
5. LES GUIDES D’APPLICATION......................................................................................................................20
5.1. Stratégie de validation d’un système d’information.....................................................................21
5.2. Qualification de conception d’un système d’information............................................................22
5.3. Qualification d’installation d’un système d’information.............................................................23
5.4. Qualification opérationnelle d’un système d’information..........................................................24
5.5. Qualification de performance d’un système d’information.........................................................25
ANNEXE 1 : PRÉSENTATION DES SYSTÈMES D’INFORMATION........................................................26
ALPHATEM SERVICES - Groupe Assystem - 31, Place Ronde - Quartier Valmy - Espace 21 - 92986 LA DEFENSE
Page : 2 / 38
[468614552.doc]
[]
Définition d’un Système d’Information.......................................................................................................26

Le CIM (Computer Integrated Manufacturing)...........................................................................................27
Partie opérative / partie commande................................................................................................................27
Partie opérative..............................................................................................................................................27
Partie commande...........................................................................................................................................27
Les interfaces entre la partie opérative et la partie commande.............................................................27
La simulation de partie opérative...............................................................................................................27
La régulation.......................................................................................................................................................27
Les automates......................................................................................................................................................27
La supervision....................................................................................................................................................27
Les afficheurs.................................................................................................................................................27
Les panneaux locaux.....................................................................................................................................27
Les superviseurs............................................................................................................................................27
Les PC de supervision..................................................................................................................................27
Le MES (Manufacturing Execution System)................................................................................................27
Le LIMS (Laboratory Information Management System).........................................................................27
Le ERP (Entreprise Resource Planning)........................................................................................................27
ANNEXE 2 : GLOSSAIRE......................................................................................................................................27
Page : 3 / 38
[468614552.doc]
[]
1 OBJET
L’objet de ce document est de présenter :
- les principes méthodologiques mis en œuvre dans le cadre de la qualification et la

validation d’un système d’information (SI),en montrant l’imbrication des activités du
projet et de la validation tout au long du cycle de vie du système,
- les guides d’application de ces principes pour la qualification et la validation de système
d’information.
Ce document comporte aussi une présentation générale des différents composants d’un Système
d’Information, ainsi qu’un glossaire définissant un vocabulaire commun à tous les utilisateurs de
ce référentiel méthodologique. Ce glossaire et cette présentation se trouvent en annexe.
2 DOMAINE D’APPLICATION
Ce document s’applique à tout projet de qualification/validation d’un système d’information,

dans le cadre d’une validation prospective.
3 DOCUMENTS DE RÉFÉRENCE
4 LES TEXTES RÉGLEMENTAIRES
[1] Agence du Médicament – BPF françaises – ch. 5 (p. 95-98) : Systèmes informatisés (1995)
[2] Agence Européenne - GMP Medicinal products for human and veterinary use, Annex 11 :
Computerised systems (1998)
[3] FDA – cGMP - Code of Federal Regulations 21CFR – parts 210, 211 (1988)
[4] FDA – CFR 21 part 11 – Electronic signatures – Electronic records
[5] GAMP 3.0 : Guide for validation of automated systems in pharmaceutical manufacture
(1998)
[6] FDA – Compliance policy guides on computerized drug processing (1987) :
- 7132a.07 – Input/output checking

- 7132a.08 – Identification of "persons" on batch production and control records
- 7132a.11 – cGMP applicability to hardware and software
- 7132a.12 – Vendor responsibility
- 7132a.15 – Source code for process control application programs
Page : 4 / 38
[468614552.doc]
[]
[7] FDA – General principles of software validation – draft guidance v. 1.1 (1997)
[8] FDA – Guideline on general principles of process validation (1987).
[9] FDA – Guide to inspection of computerized systems in drug processing (1983)
[10] PIC GMP Guide : principles of qualification and validation in pharmaceutical

manufacture - PH 1/96
5 LES GUIDES D’APPLICATION
GUI 085 Guide d’application : stratégie de validation d’un système d’information
GUI 086 Guide d’application : qualification de la conception d’un système d’information
GUI 087 Guide d’application : qualification d’installation d’un système d’information
GUI 088 Guide d’application : qualification opérationnelle d’un système d’information
GUI 089 Guide d’application : qualification de performance d’un système d’information
6 PRÉSENTATION GÉNÉRALE
7 HISTORIQUE
Le matin du 21 mars 1986, à l’hôpital du Centre de Cancérologie de Tyler dans le Texas, M.

Voyne Ray Cox, 33 ans, s’allongea sur une table pour être soumis à une de ses dernières
séances d’irradiation. Malheureusement, l’accélérateur de particules, entièrement piloté par un
programme informatique, délivra à M. Cox une dose mortelle d’irradiation. Pourtant,
l’historique de la séance présenté à l’écran indiquait que le logiciel avait considéré que le
patient n’avait même pas reçu la dose prescrite, et se terminait par le message d’erreur
laconique MALFUNCTION 54, indiquant simplement un dosage défectueux.
Après une brève vérification auprès du constructeur, l’accélérateur fut remis en marche mais
on déplora peu de temps après un deuxième accident mortel, où le message MALFUNCTION
54 avait de nouveau fait son apparition.
A la fin du mois d’avril 1986 et après une enquête approfondie, le fabricant de l’accélérateur
remettait un rapport à la FDA, dans lequel il mentionnait que le logiciel produisait une
anomalie lors de l’édition des paramètres de dosage, à l’utilisation de la touche « flèche haut ».
Les exemples de mauvais fonctionnement de programmes ne manquent malheureusement pas

et s’ajoutent de jour en jour à une longue série d’accidents. Parmi les plus graves, on trouve des
accidents de train, d’avion, de fusée ou de missiles. Parmi les moins graves, on peut citer tous
les déboires informatiques subis dans les aéroports, dans les banques, à la bourse, ou le fameux
« Bug du passage de l’an 2000 », qui a des répercussions dans tous les secteurs d’activités.
Progressivement, les instances réglementaires des secteurs concernés ont convenu de la

nécessité d’une validation des systèmes informatisés.
Page : 5 / 38
[468614552.doc]
[]
8 CONTRAINTES RÉGLEMENTAIRES
Dans le secteur pharmaceutique, la validation des systèmes d’information est encadrée par un
ensemble de textes réglementaires, qui pour l’instant dépend encore des instances
réglementaires nationales. Les contraintes qui en découlent varient donc en fonction du pays de
destination des médicaments produits. Parmi les instances réglementaires nationales les plus
importantes (celles qui représentent les plus gros marchés) on peut citer les États Unis (FDA),
l’Union Européenne et le Japon.
Les extraits de textes réglementaires ci-dessous expriment sans ambiguïté la nécessité de

valider les systèmes d’information.
 « Validation : établissement de la preuve documentée avec un haut degré d’assurance qu’un

procédé spécifique produira régulièrement les résultats escomptés en terme de qualité et
de spécifications » [8] (FDA – Guideline on general principles of process validation - 1987).
 « La validation doit être considérée comme une partie de l’ensemble du cycle de vie d’un
système informatique » ([1] : BPF chapitre 5 ou [2] : GMP CEE annexe 11).
 « Tout logiciel utilisé pour automatiser une partie du processus de production ou du système
qualité doit être validé dans l’usage pour lequel il est destiné » ([7] : FDA - General
principles of software validation –draft guidance v. 1.1 - 1997).
Les documents [1] et [2] définissent le contexte réglementaire qui s’applique en France et en
Europe à la production pharmaceutique et notamment aux systèmes informatisés, à travers 19
lignes directrices concernant le principe, le personnel, la validation et le système. Pour les USA,
les textes de référence sont établis par la FDA (réf. [9], [7], [6] et [3] notamment).
Le GAMP [5] constitue une synthèse des références réglementaires, et fournit « clés en main »
les outils pour bien maîtriser la validation d’un système informatisé, tant pour le client
utilisateur que pour le fournisseur.
Le GAMP est un document émis par l’ISPE et qui est le fruit de la collaboration :
 d’associations représentatives du secteur pharmaceutique et des Systèmes d’Informations :
APV (International Association for Pharmaceutical Technology),

NAMUR (standardization Association for Measurement),
GMA,
MCA (Medecine Control Agency),
GAMP Forum …
 de grands groupes pharmaceutiques mondiaux :
Glaxo Wellcome, Boehringer Ingelheim,
Smithkline Beecham, Schering,
Novo Nordisk, Roche,
Zeneca Pharmaceuticals, Hoechst,
Pfizer, Merck,
Lilly, Janssen Pharmaceuticals
A ce jour, le GAMP tend à devenir un standard mondialement reconnu pour la validation des
systèmes d’information.
Page : 6 / 38
[468614552.doc]
[]
 La validation des systèmes d’information est une exigence réglementaire. La mise en

œuvre de celle-ci incombe totalement à l’utilisateur final, au producteur de substance
pharmaceutique.
C’est lui qui doit être garant du bon déroulement de la validation et qui en a la responsabilité
in fine devant les instances réglementaires. Le processus global de validation doit être supporté
et contrôlé par l’utilisateur, certaines étapes peuvent être sous-traitées, mais de manière
maîtrisée.
« The heads of Production and Quality Control departments generally have the responsability
to ensure that the appropriate validations are done. » [10]
9 MAÎTRISE DU PROJET
Outre l’aspect règlementaire, la validation des systèmes d’information permet une meilleure
maîtrise dans les trois axes classiques de gestion de projet : coût, délai, qualité.
Tout au long du cycle de vie d’un Système d’Information, deux processus ou deux points de
vue vont coexister. Le processus classique de « Projet » ou « Activités de Projet » et le
« Processus de Validation ».
L’objet de ce paragraphe est de montrer combien les activités de Projet et les activités de
Validation sont imbriquées.
10 LES ACTIVITÉS DE PROJET
Les BPF imposent que la mise en œuvre d’un Système d’Information s’intègre dans un cycle
de vie, dont les principales étapes sont précisées : « la planification, la spécification, la
programmation, les essais, la réception, la documentation, l’exploitation, le contrôle et les
modifications ».
Le tableau ci-après résume les différentes activités rencontrées à toutes les étapes d’un Projet
de mise en œuvre d’un Système d’Information.
Page : 7 / 38
[468614552.doc]
[]
Activités de Projet Etapes Acteurs

Enclenchement Planification Client
Planification
Spécification des besoins utilisateurs Spécification Client
Spécifications fonctionnelles Spécification Fournisseur
Conception préliminaire Conception Fournisseur
Etudes des matériels
Etudes des équipements électriques et mécaniques
Etudes des réseaux
Etudes des logiciels
Conception détaillée
Etudes des modules logiciels
Construction /Codage Construction / Fournisseur
Construction et assemblage des matériels codage
Construction et assemblage des équipements
Construction et assemblage des réseaux
Codage des modules spécifiques
Essais unitaires Tests de Fournisseur
Tests du matériel et des équipements développement
Tests des réseaux (FAT *)
Tests des modules logiciels
Essais d’intégration
Tests d’intégration des logiciels
Installation du matériel et des équipements Installation Fournisseur
Installation des réseaux
Installation des logiciels
Recette du matériel et des équipements Recette Client
Recette des réseaux
Recette des logiciels
Essais fonctionnels Essais Fournisseur /
Essais fonctionnels des matériels et équipements fonctionnels client
Essais fonctionnels des réseaux (SAT *)
Essais fonctionnels des logiciels
Essais fonctionnels du système
Essais d’ensemble et de performance Fournisseur /
client
Démarrage de l’exploitation Fonctionnement Client
Montée en régime de l’exploitation
Exploitation
Maintenance
Gestion de la configuration
Gestion des modifications
* FAT : Factory Acceptance Tests – SAT : Site Acceptance Tests
La réglementation (BPF/GMP et FDA) n’impose aucun modèle de cycle de vie, seulement

l’exigence que celui-ci soit maîtrisé.
Page : 8 / 38
[468614552.doc]
[]
L’ensemble de ces activités est parfois représenté par un schéma en V qui présente
l’avantage de visualiser la correspondance entre les spécifications, la conception et les essais.
Spéc. besoins répond Essais d’ensemble et de

utilisateurs performance
Spécifications répond SAT

fonctionnelles Essais fonctionnels
Conception répond FAT

préliminaire Essais d’intégration
Conception répond FAT

détaillée Essais unitaires (modules)
Construction
Codage
Fig. Activités Projet : cycle en V
Cette représentation est particulièrement adaptée aux exigences de l’assurance qualité, et

permet alors un rapprochement avec le processus de Qualification/Validation qui est
détaillé au paragraphe suivant.
Page : 9 / 38
[468614552.doc]
[]
11 LE PROCESSUS DE QUALIFICATION /VALIDATION
Le processus de validation couvre l’ensemble de la vie du système, et est lui aussi représenté
sous la forme du cycle en V.
Rapport QP VMR
répond
Qualification de
Performance
Spéc. besoins
utilisateurs Essais d’ensemble et de
Protocole QP performance
VMP
Rapport QO
répond Qualification
Opérationnelle
Spécifications
fonctionnelles SAT - essais fonctionnels
Protocole QO
Rapport QI
répond Qualification
d’Installation
Conception
préliminaire FAT - essais d’intégration
Protocole QI
répond
DQ
conception FAT : essais unitaires
qualification détaillée (modules) Activités projet
de
conception
Activités
Construction Validation
Codage Document
Validation
Abréviations utilisées :
DQ : Design Qualification VMP : Validation Master Plan
QI : Qualification d’Installation VMR : Validation Master Report
QO : Qualification Opérationnelle FAT : Factory Acceptance Tests
QP : Qualification de Performance SAT : Site Acceptance Tests
Fig. processus de qualification / validation : cycle en V
Il est maintenant clair que les activités de Projet et les activités de Validation, quoique
devant être menées de manière complètement indépendante, sont tout à fait imbriquées. En
effet, le processus de Qualification / Validation d’un Système d’Information et le Projet de
mise en œuvre de celui-ci partagent de nombreuses activités ils s’appuient sur des
documents communs pendant tout le cycle de vie du Système d’Information.
Page : 10 / 38
[468614552.doc]
[]
Le processus de validation doit donc à chaque fois être adapté au projet et permettre de
coordonner et d’optimiser les activités de Projet et de Validation. Ca n’est qu’à cette
condition que les bénéfices retirés seront importants.
En effet, la mise en place, dès le début du projet, d’un processus de validation bien préparé,
adapté au projet et mené de manière rigoureuse apporte les bénéfices suivants :
 la découverte des risques, des défauts, écarts, oublis, … au plus tôt dans le projet, donc
gain de temps et réduction des coûts,
 d’atteindre le niveau de qualité logiciel désiré en terme de niveau fonctionnel,

fiabilité, ergonomie, rendement, maintenabilité, portabilité. Ces critères de qualité
devant être pris en compte dès les phases de spécification du système,
 une meilleure visibilité du management sur le projet tout au long du cycle de vie,
 la formation progressive des utilisateurs, par une appropriation progressive du système,
Il est donc essentiel pour chaque projet, de mettre en place une méthodologie de
Qualification / Validation adaptée, qui doit permettre de transformer la contrainte
réglementaire, en un processus apportant une réelle valeur ajoutée en ce qui concerne la
maîtrise du Système d’Information, et ce dans les trois axes de gestion de projet : coût,
délais, qualité. C ‘est ce que nous appellerons la « maîtrise du projet »
Page : 11 / 38
[468614552.doc]
[]
12 PRINCIPES GÉNÉRAUX
Le cycle de vie d’un SI peut être considéré selon 2 approches complémentaires :
- l’approche développement, ou approche projet, partagée à la fois par le maître

d’ouvrage et par les fournisseurs,
- l’approche validation, exercée par l’assurance qualité du client dans l’optique d’une
présentation à une autorité de tutelle.
Voyons comment se déclinent ces deux démarches dans les phases de conception et dans les
phases d’essais.
13 PHASES DE CONCEPTION
14 APPROCHE DÉVELOPPEMENT : CONCEPTION
La conception consiste en la traduction des besoins de l’utilisateur en un système.
La démarche mise en œuvre est une décomposition par découpages successifs en tâches et
éléments dont le traitement est compatible avec l’organisation et les moyens de
développement et de réalisation. Cette décomposition s’articule d’abord sur un axe
fonctionnel puis se poursuit au niveau structurel.
Parallèlement, la base des connaissances augmente au fur et à mesure de l’avancement du

processus. Pour les systèmes complexes, ces nouvelles connaissances sont régulièrement
confrontées aux besoins de l’utilisateur par l’intermédiaire de revues de conception.
Ces revues, organisées aux étapes clés du processus de développement, permettent de se

prémunir des risques de non-correspondance entre le système et les besoins. Elles facilitent
ainsi la nécessaire coordination entre le client et son fournisseur.
moyens de
production
revues de conception
tâches
élémentaires
tâches
élémentaires
tâches
élémentaires
spécifications
des besoins Décomposition tâches
utilisateur élémentaires
tâches
élémentaires
tâches
élémentaires
tâches
élémentaires
Fig. approche développement : phases de conception
Page : 12 / 38
[468614552.doc]
[]
15 APPROCHE VALIDATION : QUALIFICATION DE CONCEPTION
Pendant la phase de conception, les activités de validation sont regroupées sous le nom de
qualification de conception ou DQ (Design Qualification). Elles ont pour objectifs :
- de vérifier la prise en compte des besoins utilisateurs dans toutes les étapes de la
conception,
- de vérifier la prise en compte des contraintes réglementaires pharmaceutiques,
Cette phase s’accompagne d’audits destinés à évaluer chez le fournisseur sa maîtrise du

processus de développement.
Le DQ est de plus l’occasion d’affiner et de traduire les critères d’acceptabilité qui seront
utilisés pour la rédaction des protocoles QP, QO et QI. Et cela, en essayant de définir dès les
phases de DQ les essais qui valideront le SI.
fournisseur
conception système
é
v é
a v é
l a v
a u a l a a a
u a u u u l u
d t d a d u d
i i i t i a i
t o t i t t t
n o i
n o
n
spécifications des besoins utilisateur

contraintes réglementaires informations
nécessaires à
la
qualification /
audits validation
client DQ
Fig. approche validation : qualification de conception
Pendant les phases de conception, l’approche validation se superpose à celle de

développement, en lui étant complémentaire.
 La qualification de conception permet de répondre aux besoins de coordination du

fournisseur, tout en préparant les phases à venir de la validation.
Page : 13 / 38
[468614552.doc]
[]
16 PHASES D’ESSAIS
17 APPROCHE DÉVELOPPEMENT : PHASES D’ESSAIS
Selon l’approche développement, l’objectif des essais est de vérifier que le système
"marche". Les essais visent à réduire et maîtriser les incertitudes, c’est-à-dire les risques
projet.
 La démarche :
La démarche d’essai est symétrique à celle utilisée pour la conception. Elle repose sur une
double convergence :
- convergence structurelle, du test de l’élément isolé vers l’essai du système intégré,
Cette dynamique prolonge la phase de réalisation, par l’intégration successive des

éléments issus de la décomposition finale.
- convergence fonctionnelle, du test de la fonction élémentaire jusqu’aux essais

d’ensemble.
De la même façon, les essais sont hiérarchisés du mode de conduite le plus simple
jusqu’au mode d’exploitation le plus élaboré.
spécifications
des besoins décomposition convergence système
utilisateur
avancement projet
TE * TI * FAT SAT
conception réalisation essais
représentation représentation représentation

fonctionnelle structurelle fonctionnelle
* TE : tests élémentaires TI : tests d’intégration
Fig. approche développement : phases d’essais
A l’inverse de la conception, où l’on était passé d’une représentation fonctionnelle (les

spécifications de besoins utilisateur) à une représentation structurelle (modules
élémentaires), la phase d’essais permet de revenir au niveau fonctionnel.
Page : 14 / 38
[468614552.doc]
[]
Cette démarche de convergence des essais garantit le bon fonctionnement de toutes les
étapes amont, ce qui permet de vérifier progressivement l’ensemble du processus. A ce titre,
l’achèvement de chaque phase d’essais constitue un indicateur fiable de l’avancement du
projet.
 Le principe :
La complexité des logiciels génère fréquemment lors des essais des non-conformités qu’il
faut pouvoir traiter. Afin de disposer de toutes les ressources nécessaires à ce traitement, il
est intéressant d’anticiper une partie de ces essais chez le fournisseur.
Le principe est d’installer une plate-forme de simulation, sur laquelle les applications sont
soumises à un ensemble d’essais déportés. Les autres éléments du système en interface sont
soit installés provisoirement, soit simulés.
Selon la fidélité de reproduction du système complet en plate-forme, les essais fonctionnels

peuvent atteindre une profondeur d’investigation similaire voire supérieure à celle
rencontrée en essais sur site. Outre des conditions d’essais favorables et la facilité de prise en
compte des modifications, la plate-forme offre également un environnement privilégié pour
anticiper la formation.
 Les activités support :
Dans l’optique de transposer les résultats d’essais en plate-forme sur site, il convient de
gérer tous les éléments du système, et en particulier les différences entre les deux
environnements.
C’est un des objectifs de la gestion de configuration, qui par un ensemble d’outils, permet
l’interprétation et la réutilisation des résultats des essais, en maîtrisant les risques de non-
régression.
C’est aussi l’un des objectifs de la gestion des modifications qui permet le traitement des
non-conformités dans le cadre de l’assurance qualité du projet.
18 APPROCHE VALIDATION : PHASES D’ESSAIS
Selon l’approche validation, l’objectif des essais réalisés durant la qualification est de
prouver que le système "marche". Ces essais sont conçus dans l’optique de réduire et
maîtriser les risques produit.
Un des principes utilisés est celui du cycle en V, qui assure la correspondance entre les
phases de conception et d’essais. Les autres principes de l’approche développement sont
également mis à contribution : convergence des essais, gestion des modifications et gestion
de la configuration.
Page : 15 / 38
[468614552.doc]
[]
approche approche validation

développement
… que le système
vérifier … prouver … "marche"
réduire et
maîtriser les … … risques projet … risques produit
convergence des essais
gestion des modifications
gestion de configuration
Fig. approches développement et validation : les essais
Les essais de qualification sont traditionnellement divisés en QI, QO et QP. Une partie des
essais de QI et de QO peuvent être anticipés en plate-forme, pour profiter des facilités de cet
environnement.
Les résultats d’essais des QI et QO déportées sont ensuite réutilisables sur site, sous réserve
d’une gestion de configuration efficace.
19 ACTEURS
Démarche développement et démarche validation sont intimement imbriquées. Cependant,

il est indispensable que les équipes validation soient indépendantes des équipes
développement. Cette indépendance est à trois niveaux. Indépendance technique par
rapport aux moyens à mettre en jeux, indépendance des responsabilités par rapport aux
choix stratégiques de validation, indépendance financière.
Ceci par souci d’impartialité et ceci afin que ces deux démarches aux objectifs différents mais
complémentaires puissent être menées de front.
20 ANALYSE DE RISQUES
Tout comme pour l’approche développement, l’approche validation s’appuie sur une
analyse de risques. Cet outil a pour objectif de mettre en exergue tous les points pouvant
générer des dysfonctionnements. Une fois ces risques identifiés, une stratégie devra être
élaborée pour prouver au plus tôt que ces risques ne se sont pas concrétisés.
L’analyse de risque permet d’orienter et de doser les efforts de validation. Ces efforts sont
en effet directement proportionnels au niveau de risque du système. Ainsi, il ne sera pas
nécessaire de réaliser des tests sur des éléments du système jugés sans risque, alors que pour
les aspects du système jugés à haut risque la couverture de tests sera maximale.
Page : 16 / 38
[468614552.doc]
[]
21 ACTIVITÉS SUPPORTS
Gestion des modifications
Pendant toute la durée du cycle de vie du projet, le système subit des modifications. La
maîtrise de ces modifications impose la mise en place d’un système de gestion des
modifications, tant chez le client que chez le fournisseur.
Ce système doit pouvoir traiter les 3 types de modifications suivants :
- les non-conformités, qui imposent une remise en conformité de l’installation du

système,
- les modifications du système, qui entraînent au minimum une modification de la
documentation,
- les modifications du plan de validation.
Pour chaque type de modification, les responsabilités et les activités de chacun doivent être
clairement établies.
Gestion de configuration
La gestion de configuration est une activité qui permet de prendre en compte toutes les
évolutions du système d’information tout au long de son cycle de vie, et de garantir la
fiabilité et la disponibilité des informations gérées.
Pendant toutes les étapes de conception et de développement, la gestion de configuration est

assurée par le fournisseur. Parallèlement, le rôle du client se limite à s’assurer de la maîtrise
du fournisseur (audit).
Lors des essais, les configurations de référence (plate-forme et site) sont testées et validées.
La responsabilité de la gestion de configuration est alors confiée au client, qui utilise la
gestion de configuration comme outil pour la maintenance du système et la gestion des
modifications.
Formation
La formation des utilisateurs est une exigence réglementaire, et fait partie intégrante du
système d’information. A ce titre, la validation doit prendre en compte la formation par la
vérification des procédures et de la documentation.
Pour être validée, la formation d’un utilisateur doit s’accompagner d’une trace écrite
spécifiant précisément à quelle(s) activité(s) la personne a été formée, et avec quelle
documentation (procédure).
Page : 17 / 38
[468614552.doc]
[]
22 SYNTHÈSE : LA STRATÉGIE DE VALIDATION
La stratégie de validation à adopter pour un système d’information doit permettre de

concilier les approches de développement et de validation. Cette stratégie se traduit par la
mise en place des outils et de l’organisation assurant une coopération étroite entre d’une
part le client et ses fournisseurs et d’autre part entre l’équipe projet développement et
l’équipe validation (la partie développement et la partie validation pouvant toutes deux être
réalisées par des fournisseurs).
Elle définit des objectifs à atteindre et associe à ces objectifs une démarche. Elle est le garant
d’une validation adaptée et permet d’échapper à la sous ou sur qualité.
Elle permet une optimisation du projet à un double niveau :
- optimisation des activités de la validation, qui s’inscrivent naturellement dans la vie

du projet, sans entrer en redondance avec d’autres activités,
- optimisation des moyens, en fonction des compétences et des responsabilités de
chacun des intervenants.
Cette stratégie s’appuie sur :
- les outils d’analyse de risque, qui permettent de maîtriser les activités de validation à
chaque niveau du projet,
- l’expérience des outils de validation (audits, revues, vérifications, essais),
- la maîtrise des activités supports (la gestion des modifications, de la configuration, la
formation),
- les principes généraux d’anticipation et la volonté d’implication du client, propices à
l’épanouissement d’une relation client/fournisseur efficace.
Un schéma figurant l’ensemble des activités de validation tout au long du cycle de vie d’un
SI est présenté page suivante.
Page : 18 / 38
[468614552.doc]
[]
ACTIVITES
spécif. des exploitation

besoins QP maintenance
utilisateur
stratégie de spécif. tests tests

validation fonction- fonctionnels fonctionnels
nelles plate-forme site
spécif. tests spécif. de tests QI QO QI QO

fonctionnels conception d’intégration déportées site
du logiciel
approbation
vers cycle spécif. tests inspection retour cycle
d’intégration codage
matériel matériel
(hardware) approbation (hardware)
revues de
codage
client formation / documentation
inspection
gestion de la configuration gestion de la configuration
fournisseur
gestion des modifications gestion des modifications
installation recette validation

LA VALIDATION
choix du fournisseur
PHASES DE
plate-forme site produit
conception développement FAT SAT

Fig. cycle de validation d’un SI
qualification de conception inspections QI plate- QI

audits forme site
rédaction rédaction / approbation des domaine du VMP QO plate- QO QP
du VMP protocoles QP, QO, QI forme site
Page : 19 / 38
[468614552.doc]
[]
phases de la VALIDATION phases du PROJET
Spéc. besoins utilisateur
plan directeur de validation

dossier de consultation
Audit des Fournisseurs
Commande
DQ Spéc. fonctionnelle
approbation PAQ
DQ Conception préliminaire
DQ Conception détaillée
audit
Audits / Revues Construction/Programation
approbation + participation FAT

QI QO déportées
inspection livraison / montage
approbation + participation SAT

QI QO
Système qualifiée
QP
Système validée
Exploitation
revalidations périodiques
Fig. exemple d’intégration des phases de validation / phases du projet
Page : 20 / 38
[468614552.doc]
[]
23 LES GUIDES D’APPLICATION
Les différentes étapes de la Qualification / Validation d’un SI font l’objet de guides d’application
qui décrivent concrètement les activités à mettre en place.
ALS GAL GUI 084 ALS GAL GUI 085

PRINCIPES DE LA VALIDATION Guide d’application :
D’UN SYSTEME D’INFORMATION stratégie de validation
d’un Système d’Information
ALS GAL GUI 086

Guide d’application :
qualification de conception
ALS GAL GUI 087

qualification d’installation
ALS GAL GUI 088

qualification opérationnelle
ALS GAL GUI 089

qualification de performance
Des guides méthodologiques permettent de préciser les méthodes et les outils utilisés dans le
cadre des prestations liées aux systèmes d’information, comme par exemple :
- ALS GAL GUI 074 : gestion de configuration des SI de production

- ALS GAL GUI 078 : modification des SI de production en phase de démarrage et
d’exploitation
Des guides de rédaction sont également disponibles pour chacun des documents de qualification.
Citons pour mémoire le guide ALS GAL GUI 057 « plan directeur de validation », à utiliser lors de
l’élaboration de la stratégie de validation d’un SI.
Enfin, les aspects techniques des SI sont traités dans les TEX relatifs aux systèmes automatisés et
informatisés.
Page : 21 / 38
[468614552.doc]
[]
24 STRATÉGIE DE VALIDATION D’UN SYSTÈME D’INFORMATION
L’élaboration de la stratégie de validation est le préambule à toutes les activités de la

qualification/validation d’un système d’information. Elle doit être initiée le plus en amont du
projet, et réclame la pleine participation du client.
La concrétisation de l’élaboration de la stratégie de validation est la rédaction du plan directeur

de validation ou, dans le cas d'un système isolé, du plan de validation du système.
Le guide d’application présente 7 étapes pour l’élaboration de cette stratégie :
- étape 1 : l’identification du système,
Basée sur le principe du découpage fonctionnel, elle permet de préciser les limites et les
interfaces du système d’information considéré.
- étape 2 : la décomposition élémentaire,
A partir du découpage fonctionnel, le système d’information est décomposé selon la

nature de ses éléments : aspects matériel (équipements), immatériel (logiciel et données)
et organisationnel (opérations manuelles, de transmission et de traitement
d’information). Cette décomposition permet d’initier les analyses de risque.
- étape 3 : l’analyse de risque fonctionnel,
Cette analyse de risque évalue les fonctions du découpage vis-à-vis du risque produit
par rapport aux 4 critères suivants : classification GMP/BPF, fréquence d’utilisation,
facteur humain, criticité. Cette analyse détermine l’effort et la profondeur de la
qualification.
- étape 4 : l’analyse de risque structurel,
Cette analyse détermine à quels stades du processus de qualification (Audit, DQ, QI,
QO, QP) les 3 aspects de la décomposition élémentaire seront pris en compte.
- étape 5 : la définition des critères d’acceptabilité,
Cette étape permet de lister les critères d’acceptabilité, parmi ceux issus des
caractéristiques principales, ceux issus des contraintes réglementaires et ceux issus des
analyses de risque menées précédemment.
- étape 6 : la matrice détaillée de qualification,
Cette étape a pour objectif de mettre en concordance les exigences de validation avec les
moyens et les ressources. L’aspect planning peut également être abordé.
- étape 7 : la rédaction du plan (directeur) de validation.
Cette méthode d’élaboration d’une stratégie de validation d’un système d’information peut
aussi être aménagée en fonction de la politique du client et du niveau d’avancement du projet.
Le cycle « découpage fonctionnel  analyse de risque  critères  planification » constitue

une démarche efficace pour aborder chacune des activités de la qualification et de la validation
d’un système d’information.
Page : 22 / 38
[468614552.doc]
[]
25 QUALIFICATION DE CONCEPTION D’UN SYSTÈME D’INFORMATION
La qualification de conception ou Design Qualification (DQ) regroupe toutes les activités de la

validation qui ont lieu pendant la phase de conception et de développement du système
d’information.
Cette phase se concrétise par 2 types d’activités :
- les audits, destinés à évaluer le fournisseur du système d’information et ses méthodes :

on s’intéresse dans ce cas au processus de conception et de développement,
- les revues ou évaluations, qui s’intéressent au résultat du processus de développement
du SI.
Les audits
On distingue 2 catégories d’audits :
- les audits de prise de connaissance,
Ils ont généralement lieu très en amont du projet de développement d’un SI, et portent
sur l’assurance qualité du fournisseur, ses méthodes, ses outils, son matériel, etc.
Ils visent à choisir un fournisseur parmi plusieurs, à déterminer la confiance accordée à

un fournisseur, à évaluer ses capacités ou ses moyens, dans le but de planifier et
d’organiser les activités futures du projet et de la validation.
- les audits de vérification ou inspections.
Ces audits consistent à vérifier que les dispositions prises par le fournisseur sont bien
respectées. Les inspections portent sur la traçabilité des modifications en cours de
développement, le respect des procédures de test, la gestion des non-conformités, etc.
Chronologiquement, ces inspections sont généralement réalisées depuis les étapes de

réalisation (codage/intégration) jusqu’aux tests du fournisseur.
Les revues ou évaluations
Les revues/évaluations sont destinées à évaluer le résultat d’une étape de la conception, sur la
base de l’examen du référentiel documentaire élaboré au cours de cette étape.
A chaque étape du projet, on rédige un protocole DQ qui permet d’évaluer l’étape suivante.
Comme ce protocole est joint avec le document amont, les exigences de la validation sont prises
en compte avant la rédaction des documents aval. L’évaluation (exécution du protocole DQ)
permet alors de vérifier cette prise en compte, et le rapport d’évaluation est joint aux
remarques utilisateur pour l’étape suivante du projet.
Les 3 étapes de la conception (spécifications fonctionnelles, conception préliminaire, conception

détaillée) peuvent faire l’objet d’un protocole DQ, comportant 2 fiches d’évaluation, la première
vérifiant la prise en compte des exigences amont, la seconde portant sur la conformité aux
exigences réglementaires, aux règles de développement ou à des points plus spécifiques.
Page : 23 / 38
[468614552.doc]
[]
26 QUALIFICATION D’INSTALLATION D’UN SYSTÈME D’INFORMATION
Objet de la qualification d’installation
La qualification d’installation vérifie par rapport aux spécifications et aux exigences

réglementaires pharmaceutiques la conformité de l’installation des éléments suivants :
équipements, logiciels et données, documentation.
Domaine d’application
Le domaine d’application est défini dans le plan directeur de validation applicable au système.
Plan de la qualification d’installation
La qualification d’installation se déroule en 3 temps : rédaction du protocole de qualification

d’installation, exécution des tests, rédaction du rapport de qualification. Lorsque des essais en
plate-forme sont prévus, chaque environnement (plate-forme/site) fait l’objet d’une QI.
Contenu de la qualification d’installation
Les vérifications de la qualification d’installation font l’objet d’un protocole QI comprenant 5

fiches d’essais (FE) :
- FE 1 : Vérification de la création des procédures
L’objet de cette FE est de vérifier que l’ensemble des procédures opératoires qui seront
nécessaires au bon fonctionnement et au bon maintien de l’installation sont créées ou
sont en cours de création.
- FE 2 : Vérification de la conformité de la documentation
L’objet de cette FE est de vérifier que la documentation fournie est exhaustive et

conforme, c’est à dire qu’elle répond aux critères d’acceptabilité listés ci-après :
traçabilité (numéro, révision), lisibilité, reproductibilité, suffisance des informations et
spécificité par rapport à l’élément considéré (équipement, logiciel, données).
- FE 3 : Vérification de la configuration matérielle
L’objet de cette FE est de vérifier que la configuration matérielle de l’installation est

conforme aux documents descriptifs de l’installation, en terme d’identité, de montage et
de repérage.
Cette FE peut être complétée par la vérification de l’adressage statique si cette

vérification ne figure pas dans les documents d’essais du fournisseur.
- FE 4 : Vérification de l’installation des logiciels
L’objet est de vérifier que les logiciels ont été installés conformément à la (aux)
procédure(s) d’installation ou au(x) manuels d’installation, à partir des sauvegardes
informatiques livrées.
- FE 5 : Vérification de la configuration logicielle
L’objet de cette FE est de vérifier que la configuration logicielle de l’installation est

conforme par rapport aux documents descriptifs de l’installation.
Page : 24 / 38
[468614552.doc]
[]
27 QUALIFICATION OPÉRATIONNELLE D’UN SYSTÈME D’INFORMATION
Objet de la qualification opérationnelle
Vérification documentée que l’équipement ou le système fonctionne comme prévu dans des
plages de fonctionnement représentatives ou prévues dans ses spécifications.
Plan de la qualification opérationnelle
La qualification opérationnelle se déroule en 3 temps : rédaction du protocole de qualification

opérationnelle, exécution des tests, rédaction du rapport de qualification. Lorsque des essais en
plate-forme sont prévus, chaque environnement (plate-forme/site) fait l’objet d’une QO.
La représentativité des essais en plate-forme est fonction de la fidélité de la simulation de

l’environnement réel. Dans tous les cas, l’architecture de la plate-forme et les outils de
simulation sont adaptés aux essais à réaliser, aux résultats recherchés et à la complexité du
système à tester.
Contenu de la qualification opérationnelle
Les essais de la qualification opérationnelle font l’objet d’un protocole QO comprenant les tests
suivant sous forme de fiches d’essais (FE). Les essais débutent par les fonctions et les
actionneurs les plus simples dans le mode le plus dégradé pour intégrer de plus en plus les
éléments jusqu’au mode le plus élaboré (progressivité des essais). Sont vérifiés dans le cadre de
la QO :
- les modes de marche et leur commutation,

- les conditions de sécurité,
- les commandes individuelles, les cycles de fonctionnement,
- les alarmes, la messagerie, l’animation de la supervision,
- les sécurités d’accès, les gestions spécifiques (recettes, formules),
- les communications avec les systèmes informatisés en interface,
- etc.
Pour un système ayant fait l’objet d’essais en plate-forme, les fonctionnalités vérifiées en plate-
forme peuvent ne pas être testées sur site si les conditions suivantes sont respectées :
- le fonctionnement n’est pas lié à l’environnement : pour ces fonctions, les conditions
de mise en œuvre de l’essai en plate-forme sont fidèles et représentatives des
conditions d’exploitation sur site,
- la maîtrise des modifications est assurée entre la phase d’essais plate-forme et les essais
site : les essais ne sont pas repris si les modifications réalisées n’impactent pas les
fonctions testées en plate forme.
Les essais non réalisables ou non réalisés en plate-forme sont réalisés sur site.
Page : 25 / 38
[468614552.doc]
[]
28 QUALIFICATION DE PERFORMANCE D’UN SYSTÈME D’INFORMATION
Objet de la qualification de performance
Vérification documentée que le procédé et/ou le système dans sa globalité atteint les
performances prévues dans toutes les plages de fonctionnement prévues.
La qualification de performance consiste alors à vérifier la fiabilité et la reproductibilité du

fonctionnement du système, par rapport aux spécifications de besoins de l’utilisateur.
Plan de la qualification de performance
La qualification de performance se déroule en 3 temps : rédaction du protocole de qualification

opérationnelle, exécution des tests, rédaction du rapport de qualification.
Lorsque le système d’information est lié à un équipement, la qualification de performance du SI

est intégrée à la qualification de performance de l’équipement.
Pour les couches plus hautes de la pyramide du CIM, la qualification de performance du

système d’information est alors spécifique.
Contenu de la qualification de performance
Les essais de la qualification de performance font l’objet d’un protocole QP comprenant les tests
de performance sous forme de fiches d’essais (FE). Les essais sont directement issus des
spécifications de besoins exprimées par l’utilisateur.
La reproductibilité des performances du système est démontrée :
- dans le cas d’un processus batch (par lot ou discontinu), par 3 runs consécutifs et
conformes de l’essai,
- dans le cas d’un processus continu, par l’observation d’un fonctionnement conforme
sur une période de référence préalablement définie.
Page : 26 / 38
[468614552.doc]
[]
ANNEXE 1 : PRÉSENTATION DES SYSTÈMES D’INFORMATION
DÉFINITION D’UN SYSTÈME D’INFORMATION
La normalisation NF/ISO Z61-001 (1993) aborde le système d’information par une définition
gigogne à 3 niveaux :
- Système informatique : ensemble constitué d’un ou plusieurs ordinateurs, de

périphériques et de logiciels, et qui assure le traitement des données.
- Système de traitement de l’information : ensemble constitué d’un ou de plusieurs
systèmes informatiques et d’appareils, tels que du matériel bureautique et de
communication, et qui assure le traitement de l’information.
- Système d’information : système de traitement de l’information accompagné des
ressources organisationnelles associées telles que les ressources humaines, techniques
et financières et qui fournit et répartit des informations.
 En résumé, un système d’information se caractérise par un regroupement de matériels, de

logiciels, de données et d’activités, organisés pour accomplir un ensemble de fonctions
spécifiques.
Cette définition fait ressortir les 2 composantes d’un système d’information :
- la composante technologique, qui traduit l’appartenance du système d’information à

la technologie informatique,
- la composante fonctionnelle, qui traduit la notion de système, munie de tous ses
aspects organisationnels.
Grâce à cette approche, il est possible de décomposer le système d’information selon les 3
aspects suivants :
- Aspect matériel : équipements, capteurs, actionneurs, régulateurs, réseaux, interfaces,

automates, calculateurs, afficheurs, superviseurs, dispositifs de stockage de données,
imprimantes.
- Aspect immatériel : switchs, paramétrages, logiciels, données.
- Aspect organisationnel : opérations de relevés, de saisies, de mesures, de contrôle, de
transmission d’information, de traitement d’information.
Page : 27 / 38
[468614552.doc]
[]
LE CIM (COMPUTER INTEGRATED MANUFACTURING)
Le CIM, ou « pyramide du CIM », est un concept destiné à appréhender l’ensemble d’un

système de production automatisé.
Ce concept a été (est encore ?) utilisé pour l’automatisation/l’informatisation des activités de

production dans le but d’accroître la productivité, la flexibilité, la qualité et la sûreté. Son
principal apport consiste en une hiérarchisation des systèmes de commande en fonction du
délai de réaction et du degré de sophistication.
fichier
gestion (1 j) temps de réponse
6
inter usines
fichier
réseaux (1 h)
télécom
gestion usine
5 message/
fichier
(1 min)
gestion de ordinateurs
production
4 message
(10 s)
calculateur calculateurs temps réel

procédé
3 trame
(1 s)
conduite API, PC, calculateurs, temps réel

supervision
2 caractère
réseaux ethernet (100 ms)
traitement API, Cde num., PC indust., régulateurs, robots
1
liaisons TOR, série, 4-20 mA, réseaux de terrain
acquisition capteurs et actionneurs
Fig : la pyramide du CIM
La pyramide du CIM ne permet de rendre compte que du système de traitement de

l’information, et non du système d’information dans son ensemble.
Page : 28 / 38
[468614552.doc]
[]
PARTIE OPÉRATIVE / PARTIE COMMANDE
PARTIE OPÉRATIVE
La partie opérative est constituée par ce que l’on appelle « le procédé ». Elle comprend les
machines, les équipements, les capteurs, les actionneurs, etc. : c’est le niveau 0 de la
pyramide du CIM.
PARTIE COMMANDE
La partie commande est constituée de tous les automatismes, ce qui correspond au niveau 1
de la pyramide du CIM. Ces automatismes peuvent être logiques (ils traitent des variables
booléennes), analogiques et/ou numériques.
On retrouve dans cette catégorie les automatismes câblés (ex. : arrêts d’urgence, sécurités),
les automatismes programmés (les régulateurs, les automates, les robots/convoyeurs
automatiques, les machines à commande numérique, etc).
LES INTERFACES ENTRE LA PARTIE OPÉRATIVE ET LA PARTIE COMMANDE
LES LIAISONS TOR (TOUT OU RIEN)
L’information, unitaire, distincte et séparée est transmise sous la forme d’une différence de
potentiel ou d’un courant entre 2 fils. C’est le type de liaison privilégié pour relier les
capteurs et les actionneurs à un automate (logique booléenne).
Il existe 2 catégories de liaison TOR :
- les liaisons NO (Normalement Ouvert) qui sont à « 0 » (pas de courant) lorsqu’il n’ y a
pas d’information, et à « 1 » (courant) lorsque l’information est présente.
- les liaisons NF (Normalement Fermé) qui sont à « 1 » (courant) en l’absence
d’information et à « 0 » (pas de courant) quand l’information est présente. Ce type de
liaison est dit aussi en « sécurité fil coupé », car elle permet de détecter une rupture de
la liaison.
LES LIAISONS ANALOGIQUES
L’information, unitaire, distincte et séparée est transmise sous la forme d’une variation de
potentiel ou d’un courant entre 2 fils. Ce type de liaison est utilisé pour les capteurs de
pression, température, débit, vitesse et autres grandeurs physiques.
La liaison analogique la plus utilisée est la liaison 4-20 mA, où la variation de 0 à 100% d’une
grandeur est traduite par une variation linéaire du courant de 4 à 20 mA.
LES LIAISONS DE COMPTAGE
L’information, unitaire, distincte et séparée est transmise sous la forme de créneaux de

tension émis à fréquence très rapide. Ce type de liaison est utilisé principalement pour le
positionnement.
Page : 29 / 38
[468614552.doc]
[]
LES LIAISONS DE COMMUNICATION
Les informations, regroupées, sont transmises sous forme de caractères codés. Ce type de
liaison est utilisé pour les lecteurs codes barres, les balances et toutes les liaisons
numériques.
Les types de communications sont très variés : liaisons parallèles (ex. PC/imprimante),
liaisons séries (ex. codes barres, balances, appareils d’analyse en RS232, etc.), réseaux (de
terrain, type ethernet, etc.).
En règle générale, on parle de liaison entre 2 équipements, et de réseau pour un nombre

d’équipements supérieur.
LA SIMULATION DE PARTIE OPÉRATIVE
La simulation de partie opérative permet de tester les automatismes de la partie commande

avec la supervision associée. L’architecture du système à tester est reconstituée sur une
plate-forme, où les tests seront exécutés.
SPOC est un progiciel paramétrable sur lequel il est possible de modéliser le comportement
d’un système sans avoir à utiliser les équipements réels. Les liaisons entre l’automate et la
partie opérative sont remplacées par une liaison de communication, et le procédé réel est
modélisé par un ensemble de modules programmés.
superviseur superviseur simulateur SPOC
API API
partie opérative partie opérative
site plate-forme
Fig. exemple de plate-forme de simulation
Page : 30 / 38
[468614552.doc]
[]
LA RÉGULATION
La régulation de procédés industriels regroupe l’ensemble des moyens matériels et techniques

mis en œuvre pour maintenir une grandeur physique à régler à la valeur désirée. Lorsqu’une
perturbation ou un changement de consigne se produit, la régulation provoque une action
correctrice.
organe de
régulation
système capteur
transmetteur
régulateur
consigne
Fig. schéma de principe d’une boucle de régulation
Le PID (action Proportionnelle, Intégrale, Dérivée) est la technique la plus employée.
- action proportionnelle : S(t) = ± G . (t) + So
- action intégrale : S(t) = (t)dt

- action dérivée : S(t) = Td
où S(t) est la sortie, (t) l’écart entre la consigne et la mesure, G le gain proportionnel, So
la sortie du régulateur quand (t) = 0, Ti et Td les coefficients intégral et dérivé.
Page : 31 / 38
[468614552.doc]
[]
LES AUTOMATES
Les automates programmables industriels (API) constituent la base des automatismes d’une
unité de production. En effet, ils sont capables de traiter les automatismes logiques,
numériques et analogiques, adaptés à un environnement industriel et utilisables par un
personnel non informaticien.
Un API est généralement constitué d’un ou plusieurs racks contenant :
- une alimentation,
- l’unité centrale et de la mémoire,
- un bus qui permet de connecter les différentes cartes
d’interface et l‘unité centrale,
- des cartes d’interfaces (entrées/sorties TOR, analogiques),
- des cartes de communication (réseaux),
- des cartes spécifiques (comptage, cartes d’axe, régulation).
La programmation des API utilise des langages d’automatismes (logigramme, schéma relais,
grafcet, littéral, etc.), et s’effectue à l’aide d’une console de programmation ou par
l’intermédiaire d’un logiciel constructeur sur PC.
….. SET @32 ;

….. #42.0 ;
….. + (I5.4*I5.2) ;
….. x(@12 ;
….. RST S24 ;
***
….. GLLOQ
***
schéma relais grafcet logigrammes littéral
Fig. ; les langages de programmation d’automatismes
console automate
système
d’exploitation câble
programme
constructeur
programme API pile de sauvegarde
Fig. programmation d’un automate
Page : 32 / 38
[468614552.doc]
[]
Le fonctionnement d’un automate est cyclique. Pendant la durée d’un temps de cycle (quelques
ms), l’API scrute les entrées (les capteurs), traite les données (entrées + variables internes) et
met à jour les sorties (actionneurs). Le cycle est alors recommencé.
LA SUPERVISION
Un automate est dépourvu d’interface homme machine : il doit donc être connecté à un
système de conduite pour remonter les informations à l’opérateur et transmettre ses
commandes aux systèmes automatisés.
La supervision peut être assurée par des afficheurs (quelques caractères alphanumériques), des
pupitres et panneaux locaux, des consoles, des PC de supervision, des stations de travail, etc.
L’ensemble de ces équipements de conduite est parfois regroupé sous le terme de SCADA
(Supervision, Control And Data Acquisition).
La supervision est reliée aux autres équipements à travers un réseau de communication. La

définition des postes de supervision, du réseau et des interfaces constitue l’architecture de
conduite.
LES AFFICHEURS
Ce terme regroupe les dispositifs d’affichage constitués de quelques lignes de caractères

alphanumériques, munis ou non d’un pavé de touches de commande. Les afficheurs sont
généralement reliés aux automates par une liaison série, selon un protocole de
communication propriétaire. La programmation de l’afficheur s’effectue soit par un
paramétrage sur une console comme pour les API, soit directement à partir du pavé de
touches de commande.
LES PANNEAUX LOCAUX
Les panneaux locaux, généralement montés sur une armoire électrique, sont constitués par
un ensemble d’équipements de conduite tels que : afficheurs, voyants, boutons poussoir,
commutateurs, pavés de touches, compteurs, traceurs de courbes, etc.
Implantés directement sur le site d’exploitation, ils sont reliés aux autres équipements par
des liaisons électriques logiques et analogiques, comportant parfois des automatismes
câblés. Les équipements les plus sophistiqués peuvent être reliés par des liaisons séries ou
des réseaux de terrain.
LES SUPERVISEURS
On appelle superviseurs les systèmes munis d’un écran graphique et d’une interface de
commande (clavier, système de pointage ou écran sensitif). Les superviseurs comportent un
calculateur (parfois appelé concentrateur) échangeant avec l’API des tables de données
(visualisations et télécommandes) sur un réseau. Ce calculateur peut gérer un ou plusieurs
postes de supervision.
Les superviseurs peuvent être regroupés dans une salle de conduite, ou placés sur le lieu
même d’exploitation ; on parle alors de poste déporté.
Page : 33 / 38
[468614552.doc]
[]
LES PC DE SUPERVISION
Ils constituent une catégorie de superviseurs caractérisés par leur architecture. Ce sont des
PC équipés d’un système d’exploitation temps réel, d’un progiciel de supervision et reliés
par réseau aux autres équipements. D’autres applications (acquisition, traitement et édition
des données) peuvent également figurer sur ces équipements.
LE MES (MANUFACTURING EXECUTION SYSTEM)
Le MES est un concept de gestion de production assistée par ordinateur contrôlant les
opérations de production. Dans le cadre de l’industrie pharmaceutique, le MES permet
d’élaborer et de gérer le dossier de lot.
Le concept du MES a été standardisé par la MESA (Manufacturing Execution Systems

Association) qui en donne la définition suivante : « système procédural, visant à optimiser le
coût d’obtention de la qualité, destiné à permettre l’exploitation des données de production
pour améliorer les processus industriels ». Plus concrètement ( ! ), la MESA définit 11
fonctionnalités assurées par un MES :
- 1) gestion des ressources (resource allocation and status),

- 2) optimisation des opérations de production (operations/detail scheduling),
- 3) ordonnance ment de la production (dispatching production units),
- 4) maîtrise du contenu documentaire (document control),
- 5) enregistrement des données de production (data collection/acquisition),
- 6) gestion du personnel de production (labor management),
- 7) gestion de la qualité (quality management),
- 8) maîtrise du procédé de fabrication (process management),
- 9) gestion de la maintenance (maintenance management),
- 10) traçabilité et historique de la fabrication (product tracking and genealogy),
- 11) analyse des performances (performance analysis).
Le MES peut être construit à partir d’un ou plusieurs progiciels interfacés entre eux. Pour
répondre aux besoins de l’utilisateur, certaines fonctions seront assurées par les fonctions
standard d’un progiciel paramétrable, ou développées en langage informatique pour les
fonctions plus spécifiques.
Parmi les outils informatiques utilisés pour les MES, on trouve les logiciels de gestion
électronique des documents (GED et GED Techniques), les systèmes de contrôle de procédé, les
logiciels de GPAO, les bases de données, etc.
Il est rare qu’un MES assure toutes les fonctions définies par la MESA. Dans le cadre de
l’industrie pharmaceutique, on parle de MES lorsque le système permet d’élaborer et de gérer
le dossier de lot.
La constitution d’un dossier de lot électronique (DLE) met en œuvre les fonctions suivantes :
génération de l’ordre de fabrication (OF), gestion de la documentation de production, recueil en
temps réel des résultats de fabrication, comparaison de ces résultats aux normes choisies,
analyses et gestion en temps réel des anomalies, obtention du dossier de lot.
Page : 34 / 38
[468614552.doc]
[]
Pour plus d’informations sur les MES, se reporter au TEX NT 190 « MES dans l’industrie
pharmaceutique ».
Page : 35 / 38
[468614552.doc]
[]
LE LIMS (LABORATORY INFORMATION MANAGEMENT SYSTEM)
Le LIMS permet de gérer les activités du laboratoire de contrôle qualité. Les objectifs de ce type
de système sont d’optimiser le planning, la flexibilité et l’efficacité du laboratoire. Pour cela, le
LIMS gère les prélèvements, l’analyse des résultats, assure la traçabilité des contrôles, édite des
historiques des analyses par article, etc.
On inclut dans les fonctionnalités du LIMS toutes les opérations d’acquisition, d’organisation,
d’analyse, de stockage et d’édition des données du laboratoire.
Les fonctions essentielles d’un LIMS sont :
- génération d’un ordre d’analyse par lot : enregistrement de l’identité de l’échantillon

(n° lot, code produit),
- choix du profil analytique de chaque ordre : liste de tests + normes associées,
- édition des feuilles de travail,
- acquisition/saisie des résultats et commentaires,
- constitution des données d’analyse du dossier de lot,
- aide à l’approbation des ordres, statut,
- édition des comptes-rendus d’analyse, des bulletins d’analyse.
D’autres fonctions peuvent également être incluses dans le LIMS comme l’ordonnancement des
analyses, le suivi et la gestion du parc d’appareils d’analyse (historique d’utilisation,
maintenance préventive, étalonnages), analyse des données de contrôle (traitements
statistiques, tendances, indicateurs de qualité, de productivité, études de stabilité), etc.
Ce système est donc souvent interfacé avec d’autres systèmes, MES ou gestion de production
assistée par ordinateur.
Page : 36 / 38
[468614552.doc]
[]
LE ERP (ENTREPRISE RESOURCE PLANNING)
Le ERP est un système de gestion de production prenant en charge les aspects commerciaux et
prévisionnels de la production. Il assure :
- les prévisions d’achat des produits, à partir de l’exploitation des commandes,

- la planification de la production en fonction des capacités de production,
- l’approvisionnement des matières premières et articles de conditionnement en flux
tendu avec le plan de production,
- la livraison des produits à la date prévue.
Page : 37 / 38
[468614552.doc]
[]
ANNEXE 2 : GLOSSAIRE

API : Automate Programmable Industriel Système programmable capable de traiter les automatismes logiques numériques et
(PLC : Programmable Logic Controller) analogiques dans un environnement industriel
BPF : Bonnes Pratiques de Fabrication Document [1] et règles visant à garantir la qualité, l’efficacité, la sécurité, l’intégrité et
l’identité des produits pharmaceutiques
CIM : Computered Integrated Concept de représentation d’un système de production automatisé
Manufacturing
cGMP : current Good Manufacturing Bonnes pratiques de fabrication industrielles
Practices
DQ : Design Qualification (qualification Vérification documentée, pendant la phase de conception du projet, de la prise en
de conception) compte des exigences GMP / BPF et des besoins du futur utilisateur
ERP : Enterprise Resource Planning Système de planification des ressources industrielles
FAT : Factory Acceptance Tests Tests fournisseur réalisés en plate-forme
FDA : Food and Drug Administration Organisme réglementaire américain en charge du secteur pharmaceutique
GAMP : Good Automated Manufacturing Document [5]
Practices
GMP : Good Manufacturing Practices Règles visant à garantir les cinq valeurs d’un produit pharmaceutique : « quality,
strength, safety, purity, identity »
LIMS : Laboratory Information Système de gestion des informations appliqué à un laboratoire
Management System
MES : Manufacturing Execution System Système de gestion de production contrôlant les opérations de production
MRPII : Manufacturing Resource Système de gestion de production prenant en charge les aspects commerciaux et
Planning prévisionnels
PQP : Plan Qualité Projet Document présentant le système d’assurance qualité d’un fournisseur appliqué à un
projet
Qualification Opération destinée à démontrer qu'un matériel fonctionne correctement et donne
réellement les résultats attendus (BPF)
QI : Qualification d’Installation Vérification documentée que tous les points clés relatifs à l’installation des équipements
d’un système sont en conformité avec les normes et les exigences de conception
approuvées et que les recommandations des fournisseurs ont été appliquées de
manière adéquate
QO : Qualification Opérationnelle Vérification documentée que l’équipement ou le système fonctionne comme prévu
dans des plages de fonctionnement représentatives ou prévues dans ses
spécifications
QP : Qualification de Performance Vérification documentée que le procédé et/ou le système dans sa globalité atteint les
performances prévues dans toutes les plages de fonctionnement prévues
SAT : Site Acceptance Tests Tests fournisseur réalisés sur site
SCADA : Supervision Control And Data Équipements de conduite et de supervision
Acquisition
Système informatique Ensemble constitué d’un ou plusieurs ordinateurs, de périphériques et de logiciels, et
qui assure le traitement des données.
Système de traitement de Ensemble constitué d’un ou de plusieurs systèmes informatiques et d’appareils, tels
l’information que du matériel bureautique et de communication, et qui assure le traitement de
l’information.
SI : Système d’information Système de traitement de l’information accompagné des ressources organisationnelles
associées telles que les ressources humaines, techniques et financières et qui fournit
et répartit des informations.
TI : Tests d’Intégration Phase des tests fournisseurs permettant d’intégrer les matériels et les logiciels jusqu’à
aboutir au système complet
URS : User Requirements Specifications Document regroupant les spécifications de besoins utilisateur
Validation Établissement de la preuve, en conformité avec les principes BPF que la mise en
œuvre ou l'utilisation de tout processus, procédure, matériel, matière première, article
de conditionnement ou produit, activité ou système permet réellement d'atteindre les
résultats escomptés
VMP : Validation Master Plan (Plan Document général de validation permettant de décrire les moyens et méthodes à
Directeur de Validation) mettre en œuvre pour valider un procédé de fabrication
Page : 38 / 38
[468614552.doc]
[]

Langue

Guide Validation Informatique

Transféré par

Informations du document

Description :

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Guide Validation Informatique

Transféré par

Description :

Droits d'auteur :

Formats disponibles

ALS GAL GUI 084 00 #

TITRE : PRINCIPES DE LA VALIDATION D'UN SYSTÈME

Rédacteur : Hervé CLUZEAUD Visa :

Vérificateur : Guillaume CARDON Visa :

Vérificateur AQ : Hélène LAROUMANIE Visa :

Émetteur : Pierre GÉRUS Visa :

A : Ajouter - M : Modifier - S : Supprimer

Améliorations / Corrections à retourner au secrétariat du Groupe Support Technique

Définition d’un Système d’Information.......................................................................................................26

L’objet de ce document est de présenter :

- les principes méthodologiques mis en œuvre dans le cadre de la qualification et la

Ce document s’applique à tout projet de qualification/validation d’un système d’information,

4 LES TEXTES RÉGLEMENTAIRES

[4] FDA – CFR 21 part 11 – Electronic signatures – Electronic records

[6] FDA – Compliance policy guides on computerized drug processing (1987) :

- 7132a.07 – Input/output checking

[8] FDA – Guideline on general principles of process validation (1987).

[9] FDA – Guide to inspection of computerized systems in drug processing (1983)

[10] PIC GMP Guide : principles of qualification and validation in pharmaceutical

5 LES GUIDES D’APPLICATION

GUI 085 Guide d’application : stratégie de validation d’un système d’information

GUI 086 Guide d’application : qualification de la conception d’un système d’information

GUI 087 Guide d’application : qualification d’installation d’un système d’information

GUI 088 Guide d’application : qualification opérationnelle d’un système d’information

GUI 089 Guide d’application : qualification de performance d’un système d’information

Le matin du 21 mars 1986, à l’hôpital du Centre de Cancérologie de Tyler dans le Texas, M.

Les exemples de mauvais fonctionnement de programmes ne manquent malheureusement pas

Progressivement, les instances réglementaires des secteurs concernés ont convenu de la

Les extraits de textes réglementaires ci-dessous expriment sans ambiguïté la nécessité de

 « Validation : établissement de la preuve documentée avec un haut degré d’assurance qu’un

APV (International Association for Pharmaceutical Technology),

 La validation des systèmes d’information est une exigence réglementaire. La mise en

10 LES ACTIVITÉS DE PROJET

Activités de Projet Etapes Acteurs

La réglementation (BPF/GMP et FDA) n’impose aucun modèle de cycle de vie, seulement

Spéc. besoins répond Essais d’ensemble et de

Spécifications répond SAT

Conception répond FAT

Conception répond FAT

Fig. Activités Projet : cycle en V

Cette représentation est particulièrement adaptée aux exigences de l’assurance qualité, et

11 LE PROCESSUS DE QUALIFICATION /VALIDATION

Fig. processus de qualification / validation : cycle en V

 d’atteindre le niveau de qualité logiciel désiré en terme de niveau fonctionnel,

 la formation progressive des utilisateurs, par une appropriation progressive du système,

Le cycle de vie d’un SI peut être considéré selon 2 approches complémentaires :

- l’approche développement, ou approche projet, partagée à la fois par le maître

14 APPROCHE DÉVELOPPEMENT : CONCEPTION

La conception consiste en la traduction des besoins de l’utilisateur en un système.

Parallèlement, la base des connaissances augmente au fur et à mesure de l’avancement du

Ces revues, organisées aux étapes clés du processus de développement, permettent de se

15 APPROCHE VALIDATION : QUALIFICATION DE CONCEPTION

Cette phase s’accompagne d’audits destinés à évaluer chez le fournisseur sa maîtrise du

spécifications des besoins utilisateur

Fig. approche validation : qualification de conception

Pendant les phases de conception, l’approche validation se superpose à celle de

 La qualification de conception permet de répondre aux besoins de coordination du

17 APPROCHE DÉVELOPPEMENT : PHASES D’ESSAIS

- convergence structurelle, du test de l’élément isolé vers l’essai du système intégré,

Cette dynamique prolonge la phase de réalisation, par l’intégration successive des