UNIVERSITE DE NANTES ----- FACULTE DE PHARMACIE

Thse pour le diplme dEtat de docteur en pharmacie

2003
NOM : GRAN, Aymar
DIRECTEUR DE LA THESE : Yves PEGON professeur de Chimie Analytique
TITRE DE LA THESE :

Validation de systmes informatiss : cas appliqu EXASCAN

RESUME DE LA THESE :
La validation de systmes informatiss est devenue une tape incontournable pour toutes les industries
pharmaceutiques qui utilisent des logiciels critiques intervenant dans le cycle de vie du mdicament.
Le management de la validation des systmes les plus complexes se fait au travers dun projet. La validation
dbute en mme temps que le dveloppement du systme. Elle sarticule en plusieurs tapes que sont : le plan de
validation, lanalyse de risque, et les diffrentes tapes de la qualification (QI, QO, QP).
Plusieurs textes rglementaires BPF, FDA et GMP donnent des recommandations sur la validation des systmes
informatiss sans jamais voquer les mthodologies pratiques de la validation. La validation demeure avant tout,
un outil de la qualit.
MOTS CLES :
QUALIFICATION, VALIDATION, INSTALLATION, OPERATION, PERFORMANCE

SOMMAIRE
SOMMAIRE

INTRODUCTION

I. INTRODUCTION A LA VALIDATION DUN SYSTEME INFORMATISE

1.1 LA VALIDATION DUN SYSTME INFORMATIS ................................................................... 5

1.1.1 Dfinition.................................................................................................................... 5
1.1.2 Historique ................................................................................................................... 7
1.1.3 La classification des systmes informatiss ............................................................... 8
1.2 POURQUOI VALIDER UN SYSTME .................................................................................... 12
1.2.1 La validation, un outil de lAssurance Qualit ......................................................... 12
1.2.2 La validation, un enjeu financier .............................................................................. 12
1.2.3 La validation, une exigence rglementaire ............................................................... 14
1.3 LES TROIS TYPES DE VALIDATION .................................................................................... 19
1.3.1 La validation prospective.......................................................................................... 19
1.3.2 La validation rtrospective ....................................................................................... 19
1.3.3 La validation priodique........................................................................................... 20
II. COMMENT VALIDER UN SYSTEME INFORMATIQUE ?

21

2.1 POLITIQUE ET PROGRAMME DE VALIDATION .................................................................... 21

2.2 MTHODOLOGIE DE LA VALIDATION ................................................................................ 22
2.2.1 Les GAMP (Good Automated Manufacturing Practices) ........................................ 22
2.2.1.1 Origines .......................................................................................................................... 22
2.2.1.2 Intrts............................................................................................................................ 23

2.2.2 Management : diffrentes phases du dveloppement et validation dun systme

informatique....................................................................................................................... 23
2.2.2.1 Le cycle de vie ................................................................................................................ 25
2.2.2.2 Les tapes de la validation ............................................................................................. 31

III. CAS PRATIQUE : VALIDATION DU SYSTEME INFORMATISE EXASCAN

41

3.1 PLAN DE VALIDATION EXASCAN V3.0 .............................................................................. 41

3.1.1 Description du systme............................................................................................. 41
3.1.1.1 Gnralits ..................................................................................................................... 41
3.1.1.2 Fonctionnalits principales et interfaces ....................................................................... 42
3.1.1.3 Architecture matrielle et localisation ........................................................................... 43

3.1.2 Organisation de validation........................................................................................ 43

3.1.2.1 Stratgie et niveau de validation .................................................................................... 43
3.1.2 2 Programme gnral de la validation.............................................................................. 44
3.1.2.3 Responsabilit vis vis de la validation......................................................................... 46
3.1.2.4 Critres dacceptation du systme Exascan ................................................................... 47

3.1.3 Niveau de risque du systme Exascan...................................................................... 48

3.1.4 Matrice de qualification linstallation.................................................................... 49
3.1.5 Matrice de qualification oprationnelle.................................................................... 50
3.1.6 Matrice de qualification de performance (systmes et interfaces) ........................... 51
2

3.2 QUALIFICATION LINSTALLATION EXASCAN V3.0......................................................... 52

3.2.1 Protocole de Qualification linstallation ................................................................ 52
3.2.1.1 Objectifs.......................................................................................................................... 52
3.2.1.2 Codification des lments, des critres et des cas de tests ............................................. 52
3.2.1.3 Procdure de qualification linstallation .................................................................... 53
3.2.1.4 Spcification et conception des vrifications.................................................................. 53

3.2.2 Fiches dessais .......................................................................................................... 56

3.2.3 Rapport de qualification linstallation ................................................................... 58
3.2.3.1 Bilan des rsultats .......................................................................................................... 58
3.2.3.2 Bilans des anomalies enregistres.................................................................................. 58
3.2.3.3 Conclusion du rapport de QI.......................................................................................... 59

3.3 QUALIFICATION OPERATIONNELLE EXASCAN V3.0 .......................................................... 60

3.3.1 Protocole de qualification oprationnelle ................................................................. 60
3.3.1.1 Objectifs.......................................................................................................................... 60
3.3.1.2 Codification des fonctions, des critres, des donnes de tests, et des fiches dessais .... 60
3.3.1.3 Procdure de qualification oprationnelle..................................................................... 61
3.3.1.4 Spcification des tests..................................................................................................... 61
3.3.1.5 Conception des tests ....................................................................................................... 70

3.3.2 Fiches dessais .......................................................................................................... 74

3.3.3 Rapport de qualification oprationnelle ................................................................... 74
3.3.3.1 Bilan des rsultats des tests ............................................................................................ 75
3.3.3.2 Bilan des anomalies enregistres ................................................................................... 76
3.3.3.3 Conclusion...................................................................................................................... 77

3.4 QUALIFICATION DE PERFORMANCE EXASCAN V3.0.......................................................... 78

3.4.1 Protocole de qualification de Performance............................................................... 78
3.4.1.1 Objectifs.......................................................................................................................... 78
3.4.1.2 Procdure de Qualification de Performance.................................................................. 78
3.4.1.2 Spcification des tests..................................................................................................... 79

3.4.2 Fiches dessais .......................................................................................................... 81

3.4.3 Rapport de qualification de Performance ................................................................. 82
3.4.3.1 Bilans des rsultats des tests .......................................................................................... 82
3.4.3.1 Bilans des anomalies enregistres.................................................................................. 83
3.4.3.2 Conclusion...................................................................................................................... 83

CONCLUSION

85

ANNEXE A

86

BIBLIOGRAPHIE

87

DOCUMENT ELECTRONIQUE

89

GLOSSAIRE

90

INTRODUCTION

Depuis une dizaine danne, avec plus ou moins de clart, les notions de validation
informatique pntrent le quotidien des entreprises pharmaceutiques. Que doit-on valider ?
Comment valider ? Pourquoi valider ? Quand valider ? Voici autant de questions que se
posent les industriels, sans vraiment avoir de mthodologie concrte.
La validation des systmes informatiss est une tape incontournable l'ensemble des
systmes intervenant dans le processus de recherche, de dveloppement, de production et de
distribution ayant un impact direct ou indirect sur la qualit des produits de l'industrie
pharmaceutique. Plusieurs rfrentiels rglementaires BPF(Bonnes Pratiques de fabrication),
GMP (Good Manufacturing Practices), cGMP (current Good Manufacturing Practices)
donnent des recommandations sur la validation des systmes informatiss dans le but
dassurer une meilleure matrise des logiciels, progiciels et applications diverses ; il apparat
donc fondamental de valider les systmes considrs comme critiques et pouvant avoir un
impact sur l'intgrit des biens et des personnes.
La validation des systmes informatiss les plus complexes se ralise travers un
projet, avec diffrents acteurs ayant une tche bien prcise. Valider, cest avant tout
dmontrer la matrise dun systme en y prvenant les risques. Cest une dmarche prcise et
structure base sur des procdures et des guides, elle doit tre documente et approuve.
La premire partie de cette thse aborde les points cls de la validation informatique :
dfinitions et analyses. La deuxime partie intgre des lments mthodologiques de la
validation informatique, et pour finir la troisime partie dtaille les aspects d'une exprience
pratique de validation d'un logiciel de contrle des articles de conditionnement imprims dans
un laboratoire pharmaceutique.

I.

INTRODUCTION

LA

VALIDATION

DUN

SYSTEME

INFORMATISE

1.1 La validation dun systme informatis

1.1.1 Dfinition
La validation est lun des principaux outils de lassurance qualit. Elle permet
dobtenir des rsultats identiques avec les mmes ingrdients. Plusieurs dfinitions selon
diffrents organismes existent pour dfinir le terme de Validation qui englobe une vaste
notion. Dans le domaine du mdicament, un simple contrle de routine sur les produits finis
ne suffit plus affirmer quils rpondent pleinement des exigences de qualit, defficacit,
et dinnocuit. La validation des systmes informatiss est un processus global qui se droule
en plusieurs tapes de qualification. Les systmes informatiss concourent la fabrication du
mdicament et plusieurs textes rglementaires franais et internationaux les prcisent.
Selon les Bonnes Pratiques de Fabrications (B.P.F.), la validation est dfinie comme :
Etablissement de la preuve en conformit avec les principes des Bonnes Pratiques de
Fabrication, que la mise en uvre ou lutilisation de tout processus, procdure, matriel,
matire premire, article de conditionnement ou produit, activit ou systme permet
rellement datteindre les rsultats escompts [1]
La Food and Drug Administration (FDA) dfinit la validation de faon similaire :
Establishing documented evidence which provides a high degree of assurance that have a
specific process will consistently produce a product meeting its pre-determined specifications
and quality attributes . Ce qui signifie : Etablir lvidence documente qui assure avec un
haut degr de confiance quun procd donn fournit un produit rpondant des
spcifications et des critres de qualit prdfinis . [2]
La norme iso 8402, 2.18 dfinit galement la validation comme : la confirmation par
examen et apport de preuves tangibles que les exigences particulires pour un usage
spcifique prvu sont satisfaisantes

La validation exige donc la preuve par des documents provenant des diffrentes phases
de dveloppement du projet et des enregistrements, quun systme :
-

Satisfasse aux spcifications prdtermines.

Fonctionne et fonctionnera avec fiabilit et justesse.

Soit labri de modifications non autorises ou accidentelles.

Soit contrl priodiquement.

Les BPF dfinissent un systme informatis comme tant : Systme comprenant la saisie de
donnes, le traitement lectronique et la sortie dinformations destines tre utilises des
fins soit de rapport, soit de contrle automatique . [1]
Le message essentiel de la validation se rsume ces deux assertions : prvenir les erreurs
et prouver la scurit du produit . La Figure 1 illustre un systme informatis et son
environnement.

Figure 1 : Exemple de Systme Informatis

1.1.2 Historique

Il nest pas ncessaire de remonter trs loin pour retrouver la trace dune poque ou
pharmacie et artisanat se conjuguaient comme deux arts complmentaires au service dune
mission : le mdicament. En tant que document matre, le dossier dAutorisation de Mise sur
le March (AMM) suivait ces bonnes pratiques et tait rdig la main.
Dans les annes 80, avec lessor de linformatique, les demandes croissantes des
autorits de sant ont pour effet daugmenter le volume des dossiers. Les industriels
envisagrent ds lors le passage dune gestion essentiellement papier une gestion totalement
lectronique des dossiers. Trs vite sest pos le problme de la traabilit et ses drives, car
comment garantir lenregistrement lectronique de ces informations sans que ces derniers ne
puissent tre falsifis par la suite. Puis vint le temps de la mini et de la micro informatique,
des progiciels standards pilotant la production, les laboratoires de contrles. La validation de
systmes informatiss devient trs vite un sujet sensible pour les industries europennes
partir de 1991, lorsque plusieurs dentre elles sont bannies du march amricain en raison du
manque de fiabilit de leur systme. Les autorits de sant saisissent cette opportunit des
nouvelles technologies qui leur est offerte pour adapter les rfrentiels en vigueur. Ainsi sont
ns les termes de validation et de conformit , abords au dpart uniquement en tant
qutape finale avant linstallation. On parle plus tard de vrification et de validation du
logiciel .

Le vocabulaire de la validation stoffe au fil du temps avec les termes de

protocole

de

qualification,

qualification

dinstallation,

qualification

oprationnelle,

qualification de performance et de conception.

A ses origines, le concept de validation est n aux Etats-Unis la fin des annes 70. Le
premier document officiel dcrivant la notion de validation mane de la FDA en fvrier 1983.
Durant ces dernires annes, lutilisation de systmes informatiss pour contrler les process
de fabrication na cess de stendre. Or, ces systmes ne sont pas labri dune dfaillance
pouvant se rpercuter directement sur la qualit des produits fabriqus. La FDA, en rponse
ses interrogations, dclarait comme inquitante lutilisation de logiciels non valids et, en
1983, publiait le premier document de rfrence lusage des inspecteurs chargs dvaluer
le niveau de validation des systmes : il sagit dun guide intitul Guide to inspection of
computerized systems in drug processsing (Guide dinspection de systmes informatiss
utiliss dans la production des mdicaments), galement appel Blue Book en raison de la
couleur bleue de sa couverture. [4]

En 1991 stablit au Royaume-Uni un comit charg de faciliter les changes de

connaissances sur la validation. Il publie la premire version dun document de rfrence
appel GAMP Good Automated Manufacturing Practice . [5] A cette mme priode, deux
inspecteurs de renom : Ron Teztlaff et Tony Trill publient deux guides dinspection des
systmes informatiss reprsentant les points de vues amricains et anglais [ 6,7,8,9]. Les
principales notions abordes dans ces documents sont les suivantes :

Le cycle de vie

Limportance des modes opratoires, dencadrement et des formations

Ltablissement des protocoles de validation

La matrise des modifications du systme

En France, ces notions sur la validation vont faire leur apparition dans le chapitre 4 de
ldition 92 du guide des Bonnes Pratiques de Fabrication puis compltes dans les
paragraphes BPF 5.21 5.24 de ldition de juin 95

1.1.3 La classification des systmes informatiss

On distingue deux types de classification, dune part celle des GAMP (Good
Automated Manufacturing Practices) et dautre part la classification de la SFSTP (Socit
Franaise des Sciences et Techniques Pharmaceutiques).
La classification des systmes informatiss est complexe et dpend dun certain
nombre de facteurs. Les GAMP proposent cinq catgories de systmes en fonction du degr
dintervention du client dans les phases dimplmentation et de maintenance. On distingue
ainsi le systme construit sur mesure pour une entreprise, du systme standard du type
Excel ou Word. [20]

 Catgorie 1 : Les systmes dexploitations

Les systmes dexploitation de rfrence disponibles sur le march, et qui sont utiliss
par lindustrie pharmaceutique sont considrs comme valids. Dans tout projet, ils font partie
du processus de validation. Il convient cependant denregistrer leur nom et version lors des
tests de Qualification dInstallation (QI). Les nouvelles versions des systmes dexploitation
doivent tre revues avant leur utilisation et limpact dune modification de leur fonctionnalit
sur lapplication doit tre tudi.
Catgorie 2 : Linstrumentation de laboratoire
Les logiciels sont pilots par des instructions non modifiables par lutilisateur. Ils sont
toutefois configurables et la configuration doit tre enregistre dans la Qualification
Oprationnelle (QO) de lquipement. Limpact de la nouvelle version sur la validit de la
documentation doit tre tudi et les actions appropries engages.
Catgorie 3 : Les logiciels standards
Ces logiciels sont de types Excel ou Word. Il ny a pas dexigences de validation les
concernant, toutefois, les nouvelles versions doivent tre traites avec prcaution. Comme
pour les autres catgories, la matrise des modifications doit tre applique avec rigueur, car
les modifications de ces applications sont souvent faciles et peu scurises.
Catgorie 4 : Les logiciels configurables (paramtrables)
Ces systmes ont comme caractristique de permettre aux utilisateurs de dvelopper
leurs propres applications en configurant ou en modifiant des modules logiciels prdfinis et
aussi en dveloppant de nouveaux modules dapplication. On trouve dans cette catgorie, les
logiciels de gestion de production et de laboratoire de contrle qualit (PRODSTAR,
LIMS). Dans ces exemples, le systme et la plate forme doivent tre bien connus et
matriss avant de pouvoir tre classs en catgorie 4. Sinon, il convient dappliquer la
catgorie 5. Chaque application devient ainsi spcifique au processus du client. Il convient de
spcifier, concevoir, tester et maintenir lapplication. Une attention particulire doit tre
porte aux modules additionnels ou modifis et la configuration des modules standards.

 Catgorie 5 : Les logiciels spcifiques

Pour ces applications ou systmes spcifiques du type ERP (Entreprise Ressource Planning),
le cycle de vie complet doit tre tudi et ce, pour tous les lments des systmes de cette
catgorie. Ces logiciels grent toutes les ressources dune entreprise, ils sont constitus de
plusieurs modules (finance, comptabilit, production, achats, planning et approvisionnement,
magasins) connects entre eux et qui sont parfois interfacs avec dautres logiciels. Ce
sont les composants les plus complexes et donc les plus difficiles valider. Le Tableau I
rsume cette classification.
Catgorie
Catgorie 1
Catgorie 2

Type de systme
Systme dexploitation et infrastructure
informatique (Windows NT)
Systmes informatiss connects des
appareils de mesures, quipements de
laboratoires (logiciels de gestion des spectro.
IR, UV, HPLC)

Catgorie 3

Logiciels standards type Word, Excel

Catgorie 4

Logiciels paramtrables/adaptables au mode

de fonctionnement de lentreprise sans quil
soit ncessaire de dvelopper des programmes
spcifiques consquents (LIMS, ERP)

Catgorie 5

Logiciels dvelopps en interne ou externe,

mais construits sur mesure de manire
rpondre aux besoins de lentreprise (ERP)

Tableau I Classification des systmes informatiss selon les GAMP

La commission SFSTP a propos, une classification des systmes informatiss base

sur le degr de complexit du systme. Le Tableau II rsume cette classification.
Catgorie
Catgorie 1

Type de systme
Systme de calcul (fiche calcul Excel)

Catgorie 2

Systmes ddis (logiciels de gestion des

spectro. IR, UV, HPLC)

Catgorie 3

Systme de gestion (LIMS, ERP)

10

Tableau II Classification des systmes informatiss (commission SFSTP)

11

1.2 Pourquoi valider un systme

Trois raisons prsident la ncessit de validation dun systme informatis.

1.2.1 La validation, un outil de lAssurance Qualit

Les contrles en fin de production, sils garantissent

la qualit des produits finis,

namliorent pas la qualit de leur fabrication. Le contrle des produits finis est souvent limit
par la reprsentativit de lchantillonnage, et la sensibilit des mthodes danalyse. La
validation permet davoir confiance dans la qualit des produits quon fabrique, car elle
implique un procd bien connu et sous contrle. Valider, cest construire la qualit dans le
produit [10]. La validation permet dune part de matriser des processus mis en uvre dans
lindustrie et, dautre part de faire progresser ceux-ci afin dviter une ventuelle baisse du
niveau de qualit que procurent ces processus. Elle permet de construire la qualit au niveau
du dveloppement, des services techniques, de la production, autour dun seul but : prouver
que le procd est sous contrle. La validation permet enfin la conservation des standards
qualit depuis la conception du produit jusqu sa commercialisation.

1.2.2 La validation, un enjeu financier

La validation peut apparatre comme une contrainte dont lobjectif principal est de
satisfaire les exigences rglementaires. En ralit, les entreprises sy soumettent non pas
seulement pour les textes rglementaires mais aussi parce quil sagit dune opration
rentable.

12

La validation permet ; comme lillustre la figure 2 :

La rduction des cots de dveloppement dun systme en permettant une dtection
rapide des erreurs de conception. Une erreur logiciel cote 100 lorsquelle est
dcouverte la conception du programme, 2000 la phase de livraison et 8000 aprs
la livraison. [10]
Daugmenter les chances dobtenir un projet performant,
La rduction du cot des maintenances des systmes,
Lobtention des AMM (Autorisation de Mise sur le March) en Europe mais surtout
aux Etats-Unis, si les informations proviennent des systmes valids
La diminution des menaces de suspension ou dinterdiction de produire,
La diminution des cots dchantillonnage et de contrle,
La diminution des rejets, des retraitements et des retests du fait de la matrise des
procds,
Lamlioration des flux de production.

Figure 2 : Avantage dune validation

13

Ne pas valider peut coter trs cher, dune manire gnrale il faut souligner que le
cot dune prvention est toujours trs infrieur au cot dune rparation. Le budget
validation, en terme de ressources allou un projet est de lordre de 15 25%, certains
laboratoires lont valu moins de 5% en tenant compte des bnfices gnrs par le
systme valid. [11].

1.2.3 La validation, une exigence rglementaire

La validation informatique est indispensable pour lenregistrement des spcialits

pharmaceutiques : cest lun des critres de recevabilit des dossiers dAMM. Aujourdhui ne
pas valider un systme, cest se mettre hors la loi. Les rfrentiels suivants justifient les
raisons rglementaires.

Le guide des Bonnes Pratiques de Fabrication

Le guide des BPF constitue un guide de gestion de la qualit impos aux entreprises
pharmaceutiques par lAFSSAPS (Agence Franaise de la Scurit Sanitaire des produits de
Sant) Les lignes directrices particulires 5 de ldition 98 est essentiellement consacre aux
systmes informatiss.
Lide directrice des BPF est la suivante :
Lorsquun systme informatis remplace une opration manuelle, il ne faut pas que la qualit
du produit ou lassurance qualit en soit affecte [3]

14

Les BPF dclinent galement les notions suivantes :

-

Le matriel doit tre install dans un cadre appropri

Une description crite et dtaille du systme doit tre tablie et mise jour
rgulirement...

Les donnes ne doivent tre introduites ou modifies que par des personnes
autorises

Le systme doit enregistrer lidentit des oprateurs qui introduisent ou

confirment des donnes importantes

Toute modification dun systme ou programme informatis doit tre ralise

conformment une procdure dfinie

Les donnes doivent tre protges par des moyens physiques ou lectroniques
contre les dommages accidentels ou volontaires

Il convient de prvoir des mesures de remplacement adquates permettant le

fonctionnement des systmes qui doivent tre mis en uvre en cas de panne

Les donnes doivent tre protges par des oprations de sauvegarde effectues
intervalle rgulier

Les procdures suivre en cas de dfaillances ou darrts doivent tre dfinies et

valides

Les recommandations FDA (Food and Drug Administration)

Il fait rfrence aux validations dans les paragraphes des parties suivantes :

Part 210 : current good manufacturing practice in manufacturing processing,

packing or holdings of drugs

Part 211: current good manufacturing practice for finished pharmaceuticals

Part 820 : current good manufacturing practice for medical devices

15

Les exigences de la FDA pour la validation de logiciels sont dans le 21 CFR 211.68
(a) (b) et galement dans la partie 820 des Code of

Fdral Rgulation (CFR), plus

particulirement les recommandations du paragraphe 21 CFR 820.30 (a,f,g) qui ont pris effet
au premier juin 97. Elles concernent tout systme dvelopp aprs cette date : les projets en
cours, tout nouveau projet et tout changement de projet existant.
-

21 CFR 820.30 (a) : (1) Toute entreprise utilisant des procds de classe III, de
classe II et de classe I liste dans le paragraphe (a)(2) de cette section doit tablir et
maintenir des procdures permettant de contrler le projet afin de certifier que
toutes les exigences spcifies sont rellement rencontres.

21 CFR 820.30 (a) : (2) Les procds de classe I suivants sont soumis ces
contrles : i) les appareils automatiss utilisant un logiciel informatique. ii ) les
dispositifs lists ci-dessous : cathter, radionuclotide, tlthrapie) [12]

21 CFR 820.30 (f) : Chaque entreprise doit tablir et maintenir jour des
procdures pour vrifier la conformit du projet. Cette vrification doit confirmer
que le logiciel utilis est conforme aux exigences de dpart. Les rsultats de ces
tests (incluant lidentification du projet, les mthodes utilises, la date, les
personnes ayant effectu cette vrification) doivent tre documents .

21 CFR 820.70 (i) : Quand des ordinateurs ou les systmes de donnes

automatiss sont utiliss dans une tape de production ou du systme qualit,
lentreprise doit valider le logiciel informatique pour lutilisation qui en sera faite
selon un protocole tabli. Tous les changements devront tre revalids avant
approbation et utilisation. Ces activits de validation et les rsultats obtenus
doivent tre documents .

16

21 CFR 211.68 (a) Automatic, mechanical, and electronic equipment dcline que
les systmes informatiss doivent tre rgulirement calibrs, inspects ou vrifis
selon un programme prdfini afin de sassurer de leurs performances. Des
comptes rendus crits des tests raliss doivent tre effectus et toute modification
du systme doit tre pralablement approuve. Lexactitude des donnes
enregistres et restitues par le systme doit tre vrifie. Des copies dcran ou un
historique des oprations ralises par le systme doivent tre disponibles pour
constituer autant de preuves de la bonne ralisation des tests.

Le 21 CFR part 11 : Enregistrement et signature lectronique

Le 21 CFR part 11 est lun des textes rglementaires les plus discuts dans lindustrie
pharmaceutique. Il est applicable depuis 1997 toutes les entreprises susceptibles dtre
inspectes par la FDA [13,14]. A travers ce texte, la FDA entend tout dabord dfinir les
conditions

permettant

lutilisation

de

la

signature

lectronique

dans

lindustrie

pharmaceutique tout en prservant la scurit des patients. Cela passe par la matrise de
lintgrit des donnes lectroniques en :
minimisant la possibilit de les falsifier,
maximisant la possibilit de dtecter les falsifications
Le 21 CFR part 11 expose les conditions dans lesquelles la FDA accepte la soumission des
dossiers au format lectronique ; ces conditions concernent de nombreux aspects tels que :

lenregistrement des donnes au format lectronique

la reconnaissance de la signature lectronique

17

Un audit trail , cest dire un enregistrement de traabilit, doit prendre acte de

toutes les modifications apportes pour chacune des donnes lectroniques. Il doit contenir la
date, lheure, le nom du crateur, modificateur ou suppresseur, un statut spcifiant le motif de
la cration, modification ou suppression de linformation. Laudit trail doit permettre la
conservation du traitement de lhistorique du traitement des donnes.
Une signature lectronique des personnes habilites et qualifies avec date et heure
prcise, pour toute saisie de donnes lectroniques pouvant tre soumises aux autorits de
sant (dossiers de lots, rapports, bulletin danalyses)
La mise en conformit des entreprises pharmaceutiques aux rgles du 21 CFR part 11
est dautant plus contraignante quelle ne concerne pas que la mise en conformit des
systmes, mais galement plusieurs autres points comme ceux cits ci-dessous :

Lengagement de la direction de lentreprise

La formation des utilisateurs, informaticien et fournisseur

La responsabilisation des propritaires de signatures lectroniques

La validation des systmes informatiss concerns

La mise en place des procdures dutilisations de ces systmes

Ces rgles ne remplacent pas les rgles des cGMP (current Good Manucfacturing Practices)
mais les prcisent et les compltent. Les projets informatiques dmarrs aujourdhui dans les
socits pharmaceutiques doivent prendre en compte ces exigences.

18

1.3 Les trois types de validation

Il existe 3 approches possibles de la validation, la validation prospective la plus connue, la

validation rtrospective, et enfin la validation priodique.

1.3.1 La validation prospective

La validation prospective est mise en oeuvre ds le dbut du projet avant la mise en

exploitation du systme, et suit tout le processus de conception du systme. Dans ce cas la
qualit se construit en mme temps que le systme et se mesure chacune des phases du
dveloppement, depuis ltape de spcification jusqu sa mise en exploitation.
La validation prospective est le type de validation recommand par la FDA, car elle
permet danticiper les bug et de mettre en uvre tout au long de la conception des actions
correctives.

1.3.2 La validation rtrospective

La validation rtrospective sapplique un systme dj oprationnel, pour lequel on

entreprend posteriori une dmarche de validation, afin de le mettre en conformit avec les
exigences rglementaires. Cest une validation difficile, car souvent les systmes mettre
jour ne possdent ni cahier des charges ni spcifications dtailles permettant de corriger les
manquements dus labsence de validation.
En pratique, ce type de validation ne doit plus exister.

19

1.3.3 La validation priodique

La validation priodique consiste sassurer que les risques lis lutilisation

(scurit, formation des utilisateurs, procdure dutilisation, maintenance des matriels)
ainsi que ceux lis lvolution du systme (programme, documentation, procdures de
gestions des anomalies) sont matriss.
Tout systme informatis doit se trouver tout moment dans un tat valide. Ainsi, la
validation est un processus continu, elle doit tre effectue chaque modification directe ou
indirecte du systme, ou bien rvalue tous les 2 3 ans en labsence de modification
apparente

20

II. COMMENT VALIDER UN SYSTEME INFORMATIQUE ?

2.1 Politique et programme de validation

Avant de se lancer dans la validation du parc logiciels dune entreprise il convient
dtablir une politique et un programme de validation, qui peuvent tre les suivantes :
Toutes les installations et oprations qui peuvent affecter la qualit du produit doivent tre
valides.
Tous les systmes informatiss qui influent directement ou indirectement sur la qualit dun
produit, doivent galement tre valids [15]
La politique de validation est applicable toutes les nouvelles installations et
oprations. Les installations et oprations existantes sont valides rtrospectivement au fur et
mesure. Il convient par la suite de dfinir la mthodologie de validation (prospective,
rtrospective, contrle des changements, contenu et approbation des diffrents documents de
validation).
Il faut ensuite dfinir un programme de validation annuel, et tablir alors une liste des
projets (nouvel atelier, quipement). La validation est dfinie comme une des tapes dun
projet et une personne charge de la validation fait partie de lquipe du projet ds son
initialisation. Ceci permet danticiper le travail de validation. Il est important de rappeler que
tous les domaines ou fonctionnalits dune application ne sont pas obligatoirement soumis
validation. Les domaines comme la comptabilit et la finance ne ncessitent pas forcment
dtre valids. En revanche les fonctions de distribution, production, contrle sont impliques
par les rfrentiels rglementaires et doivent tre valides.
La direction de lentreprise approuve le projet, dsigne les responsables pour chaque
systme, apporte son soutien.

21

Figure 3 : Responsabilits des diffrents acteurs dun projet de validation

2.2 Mthodologie de la validation

2.2.1 Les GAMP (Good Automated Manufacturing Practices)

2.2.1.1 Origines

Face une rglementation pharmaceutique reste trs gnrale dans le domaine de la

validation des systmes informatiss, un certain nombre dindustriels se sont regroups et ont
cr les GAMP. Leur objectif tait damliorer la comprhension et linterprtation de la
rglementation en tablissant un guide lattention des fournisseurs et des utilisateurs des
systmes informatiss. Aujourdhui, ce guide est devenu un rfrentiel pour la validation de
systmes informatiss.

22

2.2.1.2 Intrts

Le dveloppeur doit aujourdhui non seulement connatre le mtier de lindustriel pour

lui apporter des solutions adaptes, mais galement les normes et exigences en vigueur
relatives cette industrie, afin que ces mmes solutions soient labores en adquation avec
ces contraintes.
En mettant en avant des concepts de validation ddis aux systmes informatiss, un
cycle de projet adapt, mais galement en prcisant les responsabilits des diffrents
intervenants, les GAMP offrent aux industriels une dmarche et des outils communs
permettant de mettre en uvre la stratgie de validation la plus approprie [16]

2.2.2 Management : diffrentes phases du dveloppement et validation dun systme

informatique.

La validation dun systme commence par lexpression des besoins et des

fonctionnalits crites dans un cahier des charges. Elle se poursuit par le contrle dexcution
des phases de conception et ralisation et se termine par la vrification de la conformit aux
critres dacceptation prdtermins, ou rception du systme. Pour maintenir cet tat pendant
la dure dutilisation du systme, il faut appliquer des principes de matrise des anomalies et
des modifications. La validation sapparente donc une partie du cycle de vie dun systme
informatique. Pour mener un projet de validation, il faut au pralable former une quipe projet
dans laquelle sintgre une quipe validation.

23

 Lquipe projet

Le travail de validation est organis par lquipe projet ds la phase de dfinition du

projet. Les quipes projets rassemblent :

Un coordinateur gnraliste rattach si possible au dpartement qualit et qui

est le chef de projet.

Un responsable validation garant des mthodologies et de la bonne mise en

uvre des exigences de la validation comme les prconisent les rfrentiels
rglementaires.

Des spcialistes dans leur domaine de comptence, spcialistes appartenant

aux diffrentes fonctions impliques dans le projet. (Exemple : responsable des
infrastructures techniques)

Des responsables fonctionnels de chantiers pour les gros systmes de classe V.

Lquipe validation

Cette quipe a comme tache de rdiger la documentation relative la validation et de

suivre le droulement des tests sur le terrain. Elle est constitue de spcialistes dans le
domaine pratiqu. Pour tre crdible les membres du groupe de validation doivent possder
outre leur exprience pharmaceutique, une qualification et une exprience suffisante des
systmes informatiss (Technique, rseaux, fonctionnalit du systme, automatisme) des tests
et des mthodes ( dveloppement logiciel, ingnierie etc. ...).
La validation tant un concept relativement nouveau, les entreprises saident souvent
de consultants extrieurs lentreprise pour constituer cette quipe, quand elles ne possdent
pas les comptences adquates.

24

L'objectivit et l'indpendance de dcision de la cellule de validation doivent tre

reconnues, de mme que celle de lassurance qualit et des chefs de projets. Ces dcisions
sont complmentaires et concourent toutes au mme but :

Equipe projet

Cots et dlais

Equipe validation

Validation du systme

Assurance Qualit

Produit de qualit

2.2.2.1 Le cycle de vie

Les BPF indiquent : Le degr de validation ncessaire dpend d'un certain nombre
de facteurs et notamment de l'usage auquel le systme va tre destin, de sa nature prospective
ou rtrospective et de l'introduction ou non de nouveaux lments. La validation doit tre
considre comme une partie de l'ensemble du cycle de vie d'un systme informatique .

Les phases du cycle de vie d'un systme sont toujours, et quel que soit le modle de
reprsentation adopt, les suivantes :

Dfinition des besoins

Conception

Ralisation

Installation

Rception

Utilisation

Retrait

25

La modlisation la plus aisment transposable l'ensemble des techniques de

conception, de dveloppement, de qualification et de maintenance actuellement utilise est le
cycle en V [10]. Il dtaille les phases de conception et de rception en tapes qui facilitent les
contrles de bonne excution et donc la validation du systme. Le cycle en V peut sappliquer
non seulement un systme informatis, un quipement automatis, un quipement
mcanique, mais encore tout projet dingnierie. La Figure 4 illustre un cycle en V
traditionnel.

Expression des besoins

Cahier des charges (URS)

SAT Rception client

Spcifications
fonctionnelles globales (FS)

FAT Rception client

Spcifications dtailles et
techniques (SDS)
Ralisation

Installation

Figure 4 : Cycle en V traditionnel

26

Pour mener terme un projet informatique et le valider, il faut dbuter par la phase la
plus critique : celles de lexpression des besoins, des spcifications et de la conception. Cest
la dfinition explicite de ce que le logiciel doit faire et comment. La validation est un exercice
continue qui se poursuit tout le long du cycle de vie du logiciel. Elle fait partie intgrante du
cycle de vie du logiciel [17], comme lillustre le dveloppement suivant :

Lexpression des besoins ou cahiers des charges (URS)

L URS (Users Requirement Spcification) est un document qui dcrit ce que

l'utilisateur attend du systme, notamment d'un point de vue pharmaceutique, il permet
galement de dgager les paramtres critiques qui seront tester dans d'autres phases de la
qualification. Il ne doit pas comporter de solutions techniques. LURS doit tre le plus
complet et le plus ouvert possible pour tenir compte des exigences prcises de lutilisateur (y
compris en matire dassurance qualit) et pour profiter des facults cratrices des
fournisseurs qui pourront ainsi proposer les solutions les mieux adaptes.
Dans ce document l'utilisateur dcrit ce qu'il exige en terme de qualit des points critiques
du systme. Les exigences de qualit relatives la construction mme de la machine. Les
exigences de productivit (vitesse dexcution, cadence) ainsi que les tolrances admises.

27

 La conception (spcifications fonctionnelles globales et techniques)

La phase de conception permet au fournisseur de garantir :

son client, que le produit quil souhaite lui vendre correspond celui quil
attend

quen interne, ses quipes en charge de la ralisation du produit connaissent le

rsultat auquel elles doivent parvenir.

Spcification Fonctionnelle globales (FS)

Les spcifications fonctionnelles FS (Functional Specification) constituent la rponse
du fournisseur la demande exprime par le client dans le cahier des charges. Elles doivent
dcrire comment le fournisseur va procder pour remplir point par point les fonctionnalits
exigibles, pour rpondre aux contraintes ergonomiques, techniques, rglementaires ou
d'environnement exprimes.
Elles doivent tre suffisamment explicites pour permettre au client de dcider si les
solutions proposes lui conviennent, et devraient accompagner l'offre commerciale dfinitive
aprs avoir t formellement acceptes par celui-ci. Elles serviront de base l'laboration des
critres d'acceptation de la rception usine (FAT : Factory Acceptance Test) qui autorisera le
fournisseur effectuer la livraison.
La rdaction de ce document est de la responsabilit du fournisseur ainsi que son
approbation (revue de contrat). Une revue pour acceptation est de la responsabilit
contractuelle du client.

28

 Spcification dtaille et technique (SDS)

Le SDS (Software design Spcification) est un document joint aux spcifications

fonctionnelles, les spcifications dtailles prcisent pour un type d'opration le traitement
dcrit dans les spcifications fonctionnelles globales. Pour un logiciel, elles modlisent au
plus fin les algorithmes programmer, elles indiquent le ou les langage(s) de programmation,
les structures de donnes et/ou de fichier. Elles permettent d'laborer les tests informatiques
(TU: tests unitaires et tests d'intgration).
Les SDS (Software Design Specification) ou spcifications techniques dcrivent avec
prcision les composants matriels et/ou mcaniques, le systme d'exploitation et les couches
logiciel utiliss, les contraintes techniques d'environnement (lectriques, raccords fluides si
ncessaire, temprature, humidit, pression ou autres) qui permettront au systme de
fonctionner comme prvu, avec les performances attendues.
Ces spcifications techniques permettront d'laborer les procdures d'installation et
d'en dduire les critres de conformit.
La rdaction et l'approbation de ces documents sont de l'entire responsabilit du fournisseur.
Une revue doit tre pratique par le client dans le cadre du processus de matrise des
fournisseurs.

La ralisation ou codage
Le codage est effectu par les concepteurs du systme qui sengagent respecter
scrupuleusement les spcifications tablies. Cette phase de ralisation matrialise la
conception. Elle doit tre soumise des rgles prtablies. Elle comprend galement la
ralisation de la documentation qui permet d'utiliser, d'installer et de maintenir le produit
ralis.

29

 Linstallation
La phase d'installation ne peut tre pratique que sur le site du client, mais il est
prfrable qu'elle soit d'abord effectue sur le lieu de ralisation (y compris en simulant des
connections particulires inexistantes), afin de pouvoir procder la rception usine (FAT).
Lors de l'installation sur le site de lindustriel :
- le client a la responsabilit de fournir un environnement technique qui corresponde aux
exigences spcifies du fournisseur,
- le fournisseur a la responsabilit de l'installation du produit fourni, et doit dlivrer
lentreprise l'ensemble de la documentation relative au systme.
La preuve de bonne installation sur le site client appartient donc conjointement au fournisseur
et son client.

La rception usine FAT (Factory Acceptance Test)

La rception usine est mene sur le site de ralisation du produit, elle permet au client
de vrifier avant expdition, que ce qui va lui tre livr correspond aux spcifications qu'il a
acceptes contractuellement. Elle consiste gnralement en une srie de tests, prdtermins
partir des critres tablis dans l'analyse fonctionnelle. Elle est effectue en prsence du client,
et se traduit par une vrification de la documentation fournie avec le produit (manuel
opratoire, conditions et procdure d'installation, contrat ou manuel d'entretien et maintenance
ou tout autre document pertinent) et galement par une revue de rsultat des tests oprs par le
fournisseur avant installation.
Le fournisseur est responsable de l'laboration des protocoles de test de FAT; ceux-ci
sont signs pour approbation par le client.
La responsabilit du droulement des tests et de l'enregistrement de leurs rsultats est
conjointe; les rsultats de test doivent tre signs par les deux parties.
La signature d'acceptation du FAT est de la responsabilit du client qui autorise par celle-ci la
livraison du produit sur son site dutilisation. Les FAT comme ils sont dcrits prcdemment,
peuvent prendre plusieurs sens selon les systmes valids. Dans le cadre dun systme de
classe 5, les FAT sont tests excuts pendant la phase de QO (Qualification Oprationnelle).

30

 La rception site SAT (Site Acceptance Test)

Aprs installation sur le site client, la phase de rception dfinitive consiste vrifier
en prsence du fournisseur, que le produit install fonctionne tel que construit , dans son
environnement d'utilisation, en accord avec les besoins et exigences exprims dans le cahier
des charges.
Le client est responsable de l'laboration des protocoles de test de SAT, ceux-ci
peuvent tre soumis au fournisseur pour approbation.
La responsabilit du droulement des tests et de l'enregistrement de leurs rsultats est
conjointe; les rsultats de test doivent tre signs par les deux parties.
La signature d'acceptation du SAT tient lieu de rception dfinitive et marque le dbut de la
priode de garantie si celle-ci est prvue.

Exploitation- maintenance
Tout au long de la vie du produit, les utilisateurs doivent tre forms son utilisation,
respecter les modes opratoires dcrits dans les manuels utilisateurs. Le produit doit faire
lobjet d'une maintenance corrective et prventive qui soit en accord avec les
recommandations du fournisseur, en appliquant les systmes de matrise des anomalies, des
modifications, des configurations matrielles, logicielles et documentaires, et ce jusqu' son
retrait.

2.2.2.2 Les tapes de la validation

Le processus de validation exige que, sur le site utilisateur, soit mise en place ds le
dbut du projet la procdure de matrise de la documentation du systme. En effet, tout au
long des tapes de qualification, les documents de conception doivent rester en adquation
avec les lments raliss, rceptionns et installs sur le site utilisateur. Les tapes de la
validation sintgrent facilement dans le cycle en V traditionnel, comme lillustre la Figure 5

31

Figure 5 : Cycle en V et validation dans environnement rglement

La validation des systmes informatiss dmarre par llaboration commune du Plan

Qualit du Projet (PQP) sous la responsabilit du fournisseur. Ce document dcrit les taches
du fournisseur et du client ainsi que la manire dont sera mis en uvre le niveau de qualit
exige par le client. La validation se poursuit selon les tapes suivantes :

Qualification de conception et de dveloppement (QC&D)

Cette tape nest pas rglementairement obligatoire, mais elle est ncessaire au bon
droulement de la validation. Il sagit dans cette tape de vrifier que le systme en cours de
prparation satisfait aux exigences pralablement dfinies (cahiers des charges) et que les
lments critiques sont bien matriss. Lapplication doit correspondre parfaitement
lutilisation envisage. La qualification de conception consiste globalement effectuer phase
par phase, une planification et un suivi document des activits de conception et de
dveloppement menes par le fournisseur.

32

Cela passe par :

Laudit fournisseur
Cet audit permet de vrifier que le fournisseur a plac son organisation sous assurance

qualit et vrifier que le produit a t construit suivant cette organisation, le rsultat de cet
audit doit tre satisfaisant. Pour satisfaire aux exigences rglementaires BPF ou 21 CFR part
11, les points vrifier plus particulirement au cours de cet audit portent sur la validit et
l'application des systmes de :
- matrise documentaire,
- matrise des anomalies,
- matrise des modifications,
- matrise des configurations pour les logiciels livrables, les logiciels et les matriels supports
des environnements de dveloppement et de test.

La revue formelle commune du CdC (cahier des charges) pour s'assurer de

l'exhaustivit des besoins, exigences et contraintes exprims par les utilisateurs et de
leur bonne comprhension par le fournisseur.

La revue et signature pour acceptation des spcifications fonctionnelles par le client.

La revue de fin de phase portant sur la documentation produite par le fournisseur

pendant lexcution des phases FS et SDS.

33

 Plan de validation (VP)

Ce plan rappelle tout d'abord les objectifs et la porte du systme, la description
fonctionnelle et technique de l'application de manire brve. Il dfinit l'organisation du projet
en termes de ressources et de responsabilits et enfin dcrit la documentation requise pour
mener bien cette validation.
Puis il pose les objectifs de la validation avant de prciser :

La constitution de l'quipe de validation

La planification de la validation

La documentation produire (ou citer) dans le cadre de cette activit,

La mthodologie de validation et la description des plans de tests raliser

Les ressources internes ou externes

La gestion des non-conformit

Les rfrentiels rglementaires

Les responsabilits

Les instructions relatives au rapport de validation et la dcision finale sur

l'acceptation du produit,

Les instructions relatives et l'exploitation et la maintenance

Lanalyse de risque (ARI)

Lanalyse de risque doit tre faite au dbut du projet, la phase de conception. Les
objectifs de l'analyse des risques sont de trois ordres :

prvoir, par une analyse pralable des risques potentiels du systme effectue ds la
phase de conception

justifier, par l'tablissement d'un rationnel de validation

prouver, en dterminant le contenu des diffrentes phases de la validation:

qualification de conception (QC), qualification d'installation des matriels et logiciels
(QI), qualification oprationnelle et tests fonctionnels (QO), qualification de
performance (QP) incluant les aspects formation organisation et procdure.
34

LARI permet de justifier la pertinence des tests effectus et dorienter leffort de

validation sur les points critiques. Il existe deux types dapproches de la validation dans le
domaine :
- Lapproche systmatique qui consiste produire une masse de documentation pour
tous types de systmes avec plus ou moins de garantie, visibilit, pertinence, mise jour.
- Lapproche avec analyse de risque qui consiste analyser au pralable les ventuels
risques afin de proposer des actions de validations adaptes. On assure ainsi dautant mieux,
la qualit, les cots et dlais et la scurisation du systme.
On distingue trois grandes classes de risques :

risques lis l'utilisation du systme

risques lis au processus de dveloppement et d'intgration du systme

risques lis aux donnes et leur implication dans les aspects qualit et rglementaires
(BPx, 21CFR Part 11, etc.).
Il existe de nombreuses mthodes permettant de construire une image raliste des

risques associs l'utilisation d'un systme informatis. Le systme le plus simple consiste
partir des spcifications fonctionnelles dtailles, de dterminer les proprits critiques de
chaque fonction, et de leur attribuer un risque selon une gravit variant de 0 2 : la gravit 0
correspond au risque nul ; la gravit 1 correspond au risque financier; la gravit 2 correspond
au risque qualit des BPF.
Ainsi les fonctions les plus critiques seront testes sous tous les angles lors des
diffrentes phases de qualification. La fonction saisir une dcision dutilisation (DU) au
laboratoire de contrle naura pas la mme criticit que la fonction lancer une demande
dachat (DA)au service achat.

35

 La Qualification dInstallation (QI)

Elle permet d'apporter la preuve que chaque lment du systme a t bien install en
accord avec les recommandations et spcifications de l'environnement technique dcrites par
les fournisseurs, qu'une fois l'installation termine le systme peut tre utilis, et que la
documentation d'utilisation et de maintenance ncessaire est prsente. La QI se droule en 3
tapes :

La rdaction des protocoles qui dcrivent lorganisation gnrale des tests de

la qualification dinstallation, les critres dacceptations, les cas de tests et leur
regroupement en fiche de test.

Les fiches de tests : droulent les scripts de tests par tape.

Le rapport de QI : rsume tous les rsultats des tests, clture et statue sur la
validit des tests effectus en fonction des anomalies

La Qualification Oprationnelle (QO)

Elle suit la phase de QI, elle permet d'apporter la preuve documente que le systme,
dont l'installation a t pralablement qualifie, permet d'excuter comme dcrit dans les
spcifications fonctionnelles, et en conformit avec les critres d'acceptation spcifis, toutes
les fonctions prvues. Et ce, dans toute l'tendue des limites prcises. Elle permet galement
de vrifier tous les aspects de scurit intrinsque et de robustesse exigible du systme. Elle
permet de tester les fonctions du systme prises sparment et donne une image instantane
vide de celles-ci. La QO se droule en 3 tapes :

La rdaction des protocoles qui dcrivent lorganisation gnrale des tests de

la qualification doprationnelle, les critres dacceptations, les cas de tests et
leur regroupement en fiche de test.

Les fiches de tests : droulent les scripts de tests par tape.

Le rapport de QO : rsume tous les rsultats des tests, clture et statue sur la
validit des tests effectus en fonction des anomalies.
36

 La Qualification de Performance (QP)

Elle permet d'apporter la preuve que le systme tel que construit , dont l'installation
et les fonctionnalits ont t pralablement qualifies, fonctionne dans son environnement rel
d'utilisation, en conformit avec les critres d'acceptation prsents dans le CdC, et produit les
rsultats conformes escompts. Elle consiste contrairement la QO effectuer un certain
nombre de tests sur le systme complet en phase dexploitation et valuer les situations de
dviations possibles. Elle se droule tout comme les autres en 3 tapes, avec une premire
partie des fiches de tests qui consiste la vrification documentaire dexploitation du
systme (formations des utilisateurs, procdures de matrise des modifications, etc..). La QP
va chercher dmontrer quun systme informatique reste fiable dans la dure.
Si des anomalies apparaissent en cours de tests, lquipe validation tablit des fiches
danomalies et une liste dactions correctives apporter. Les modifications dun programme
du systme sont suivies par de nouveaux tests. Chaque tape de qualification doit tre
approuve dans lordre (QI, QO, QP) avant le passage aux tapes suivantes.

Les Procdures et Instructions de la validation

Plusieurs documents recommands par les rfrentiels BPF et FDA accompagnent la
validation, ce sont les procdures de change control, la formation des utilisateurs, les manuels
utilisateurs etc..) [19]

Le manuel utilisateur

L'utilisateur doit crire des instructions gnrales prcisant les procdures suivre
pour utiliser le systme informatis. Elles seront disponibles avant la mise en route du
systme et serviront de rfrence pour la formation du personnel.

37

 La formation des utilisateurs

La mise en place d'un outil informatique ne se limite pas sa mise en exploitation, il
est indispensable que les gestionnaires ou administrateurs d'une part et les utilisateurs
dautre part soient forms.
Les personnes assumant des responsabilits doivent recevoir une formation approprie en
vue de la gestion et de l'utilisation des systmes informatiss dans leur domaine de
responsabilit (annexe 11.1 GMP dition 99).
Cette formation a pour but de familiariser les utilisateurs l'outil informatique et aux
modifications induites par son installation.
En effet, avant la mise en exploitation du logiciel les utilisateurs doivent :
- connatre le logiciel et l'environnement associ
- matriser le logiciel afin d'amliorer leur faon de travailler et mettre profit l'outil (en terme
de temps et de technique)
- savoir faire face aux problmes ventuels.
Le temps consacr ces formations varie dans de larges proportions en fonction de la
complexit du systme, du rle des utilisateurs et de leur nombre. La formation initiale est le
plus souvent ralise par le dveloppeur. Le propritaire du systme tablit par la suite un
plan de formation pour lensemble des collaborateurs, dterminant quelle formation est
ncessaire et pour quels utilisateurs. Les enregistrements relatifs la formation du personnel
doivent tre conservs en permanence. [18] La formation est un processus continue et doit
sadresser chaque nouveau collaborateur.
La formation des utilisateurs a pour rle de :

Prsenter et dmontrer les fonctionnalits du systme

Expliquer et montrer les intrts du logiciel en matire de gain de temps et de qualit

38

 Le Change Control ou (matrise des modifications)

Ce processus assure la gestion des modifications du systme ainsi que l'identification
et la traabilit des versions du systme durant son cycle de vie. Elle inclue le contrle des
modifications et la matrise de la configuration. Toute modification est contrle et approuve
par le service informatique et le service Assurance Qualit, son impact sur le statut valid
du systme est dtermin par le groupe de validation.
Le propritaire du systme et les utilisateurs doivent tablir et tenir jour des
procdures pour enregistrer, grer et rendre compte de l'tat des constituants, des demandes de
modifications et de la ralisation des modifications acceptes. Mettre en uvre le change
control, cest sassurer que toutes les modifications survenant lors de lexploitation du
systme ne gnre pas un risque pouvant impacter tout le systme.
Il existe des modifications qui ne ncessitent pas une nouvelle validation ou seulement
une validation de la seule fonctionnalit modifie.
Toutefois, il ne suffit pas de revalider juste le changement qui a eu lieu mais on doit effectuer
des tests de non rgression au regard de lanalyse de risque pour dmontrer que les parties non
impliques n'ont pas t touches par inadvertance.

Matrise de la scurit
Comme les modifications, la scurit doit tre approuve par le service informatique.
L aussi, une procdure gnrale dcrit les principes, les rles, les responsabilits et la
documentation ncessaire. Le propritaire du systme et les utilisateurs tablissent des
procdures de scurit pour la protection du systme informatis. Cette matrise de la scurit
passe par:

La scurit physique avec toutes les prcautions prises pour protger le

systme de son environnement (antivirus)

La scurit logique avec lensemble des prcautions prises pour protger le

programme et les donnes (antivirus etc..)

Les BPF (Lignes directrices particulires 5 chapitre 8) le prcise Les donnes doivent tre
protges par des moyens physiques ou lectroniques contre les dommages accidentels ou
volontaires

39

 Le rapport de validation
Le rapport de validation tablit la preuve que les installations, les manuels utilisateurs, la
formation des utilisateurs et les procdures relatives l'exploitation du systme sont adaptes,
que l'application est qualifie et matrise, et que sa qualit est conforme aux exigences
tablies.
Il doit galement permettre d'identifier les problmes rencontrs et prvoir leur rsolution voir
indiquer les rsolutions en attente et qui n'ont pas de consquence critique. Il comporte les
comptes-rendus des diffrentes tapes de qualification, la confirmation du respect des
spcifications ainsi que l'approbation du responsable de la validation.
Lorsque le rapport ne contient aucune anomalie bloquante pour la mise en exploitation
dfinitive, le propritaire du systme informe par une note interne tous les acteurs du projet, la
validation et le dploiement de lapplication. Cette note saccompagne de la signature du
procs verbal de recette finale du projet qui traduit lacceptation officielle par le propritaire
du systme et lassurance qualit du produit fini. Cette signature marque donc lachvement
de la phase de ralisation du projet.

Le cas pratique Exascan qui sera tudi dans la suite de cette thse est un systme
informatis qui pourrait tre class en catgorie 2 selon les GAMP. Ce systme est destin au
contrle des articles de conditionnements imprims (tuis et notices). Ce systme est peu
complexe et na pas ncessit la mise en place dun projet. Ce travail a t excut dans le
cadre dun stage pratique de Dess (diplme dtude suprieur spcialis). Il dcline les
diffrentes phases de la validation du logiciel Exascan

40

III. CAS PRATIQUE : VALIDATION DU SYSTEME INFORMATISE

EXASCAN

3.1 Plan de validation Exascan v3.0

Le rle du plan de validation est de dfinir et planifier les activits raliser, les
documents utiliser, les responsabilits et les ressources associes aux tapes de validation de
lExascan. Ce plan est tabli en sappuyant sur des textes de rfrences et des procdures de
validation internes lentreprise :

21 CFR 11 - Electronic Records, Electronic Signatures. Federal register vol 62 N 54

Thursday 20 March 1997

Commission europenne DG III Good Manufacturing Practice (Edition 1999)

Annexe 11

Bonnes Pratiques de Fabrication (98/5bis AFSSAPS) Lignes Directrices

Particulires (LDP) Chapitre 5

CSV Guidelines Entreprise Computerized Systems 1er Juillet 2001 V. 2.0

Principes gnraux suivre pour la ralisation dune qualification et/ou dune

validation

Conduite des tests de qualification et validation

Procdure de dclaration d'une anomalie et / ou d'une demande de modification au

sein d'un systme informatis.

Guide dutilisation du logiciel Exascan V3.0

3.1.1 Description du systme

3.1.1.1 Gnralits
Le systme informatis Exascan est un systme de contrle des articles de
conditionnements imprims, de type mono-poste et multi-utilisateurs bas sur le logiciel
Exascan.

41

3.1.1.2 Fonctionnalits principales et interfaces

Les diffrentes fonctionnalits du systme informatis Exascan sont les suivantes : [21]

Gestion des donnes techniques :

Il existe 3 profils daccs au logiciel Exascan, le profil administrateur possde tous

les droits de cration, modification, suppression des autres profils et mots de passe
ainsi que tous les autres droits du superviseur et de loprateur. Le profil superviseur
possde les droits de cration des modles ainsi que tous les autres droits de
loprateur. Le profil oprateur possde les droits dexcution du contrle en routine.

Interface utilisateur :

Laccs Exascan ncessite un identifiant et un mot de passe.

Gestion des modles.

Les profils administrateurs et superviseurs peuvent crer des modles darticle de

conditionnement. Pour crer un modle, il faut le scanner puis le calibrer et le
modliser. La calibration se fait en positionnant deux croix diamtralement opposes
sur larticle de conditionnement de manire le figer pour les contrles venir. Ce
positionnement devra tre le mme que celui des chantillons lors du contrle. La
modlisation se fait en choisissant une nuance de couleur de gris sur larticle de
conditionnement. Cela permet au logiciel de dterminer le contraste dans lequel il
pourra comparer le modle lchantillon lors du contrle.

Contrle des chantillons :

Le logiciel compare le modle cr lchantillon lors du contrle en routine puis

donne le nombre de diffrence lissue de la comparaison.

Edition dun rapport de contrle.

A la fin du contrle, loprateur a la possibilit dimprimer un rapport de contrle.

42

Traabilit et gestion des enregistrements.

Il existe une base de donne qui permet de tracer tous les contrles effectus dans
une priode donne ainsi que les dates et heures de crations des diffrents modles.
Le systme Exascan nest reli aucune interface.

3.1.1.3 Architecture matrielle et localisation

Voir lannexe A

3.1.2 Organisation de validation

La validation du systme informatis Exascan est une validation prospective avant mise
en exploitation.

3.1.2.1 Stratgie et niveau de validation

La validation du systme Exascan est restreinte :

aux processus les plus critiques soumis la rglementation pharmaceutique

couverts par le systme,

aux fonctions et interfaces logicielles critiques qui composent ces processus,

aux composants matriels et logiciels critiques qui supportent ces fonctions et

interfaces logicielles.

La validation du systme Exascan est adapte en fonction des risques lis son
utilisation.
Pour chaque niveau d'abstraction, une analyse des risques est ralise pour orienter les
activits de validation.

43

3.1.2 2 Programme gnral de la validation

La validation du systme informatis EXASCAN contient les tapes suivantes :
Etape1 - Organisation de la validation
Objectifs :

Organiser et planifier de manire dtaille le projet de validation

Dfinir les critres dacceptations dtaills de chaque composant du systme (logiciel,

matriel, processus, ....) en accord avec les exigences rglementaires applicables,
permettant de vrifier la conformit du systme.

Documents utiliss :

Documents fournisseur (cits en rfrence)

Documents de validation (cits en rfrence)

Rfrentiel rglementaire

Documents dlivrs :

Plan de validation informatique approuv.

Identification des risques. Jointes en annexes

Etape 2 - Prparation des qualifications

Objectifs :

Prparer les documents ncessaires lexcution de la validation du systme.

Rdiger, pour les composants critiques, des essais de mise en dfaillance du systme.

Documents utiliss :

Identification des niveaux de risques

Documents fournisseur (cits en rfrence)

Documents de validation (cits en rfrence)

Rfrentiel rglementaire

44

Documents dlivrs :

Protocoles et fiches de qualification dinstallation (QI) approuvs

Protocoles et fiches de qualification oprationnelle (QO) approuvs

Protocoles et fiches de qualification de performance (QP) approuvs

Remarques :
-

Lordre de rdaction des protocoles et des fiches dessai de QI, QO et de QP nest pas
impos.

La QP est spare en deux parties : avant et aprs mise en exploitation du systme

informatis.
Etape 3 - Excution des qualifications.

Objectifs :

Excuter les tests

Construire la dmonstration justifiant la validit du systme partir des protocoles rdigs

ltape 2.

Documents utiliss :

Protocoles et fiches de qualification dinstallation (QI) approuvs

Protocoles et fiches de qualification oprationnelle (QO) approuvs

Protocoles et fiches de qualification de performance (QP) approuvs

Documents dlivrs :

Rapports de qualification dinstallation (QI) approuvs

Rapports de qualification oprationnelle (QO) approuvs

Rapports de qualification de performance (QP) approuvs

Anomalies de QI, QO, QP enregistres

Remarques :
-

La QO ne peut tre excute sans avoir pralablement approuv le(s) rapport(s) de QI

La QP avant mise en exploitation ne peut tre excute sans avoir pralablement approuv
le(s) rapport(s) de QO

Le systme informatis ne peut pas tre mis en exploitation sans lensemble des rapports
approuvs.

Le rapport final de validation est rdig suite lexcution de la QP aprs mise en

exploitation.
45

 Etape 4 - Exploitation et maintenance du systme

Objectifs :

Maintenir le systme valid

Matriser les modifications du systme conformment aux procdures de contrle du

changement.

Effectuer une revue priodique de ltat de validation du systme

Sassurer que lexploitation et la maintenance du systme sont sous contrle.

Documents utiliss :

Procdure de gestion des modifications des systmes informatiss (cite en rfrence).

Documents dlivrs :

Demande dvolution traite

3.1.2.3 Responsabilit vis vis de la validation

Les responsabilits vis vis de la validation sont les suivantes :
Structure
Assurance
Qualit

Stagiaire
DQ/CdQ

DQ/CdQ
Support
Technique
Pharmaceutique
Technique
Informatique

Responsabilits
approuve le plan de validation
approuve les analyses de risques
approuve les protocoles de QI, QO, QP
approuve les rapports de QI, QO, QP
approuve le rapport final de validation
rdige le plan de validation
rdige les analyses de risques
rdige les protocoles (QI, QO, QP)
rdige les rapports (QI, QO, QP), rapport final de validation
s'assure du suivi et du traitement des anomalies constates aprs
excution des tests
Vrifie les analyses de risques
Vrifie le plan de validation
Vrifie les protocoles (QI, QO, QP)
prpare les donnes et les pr-requis pour les tests et les
vrifications
excute les tests et les vrifications
Vrifie les rapports (QI, QO, QP), rapport final de validation

46

3.1.2.4 Critres dacceptation du systme Exascan

La validation initiale de lEXASCAN sera termine lorsque toutes les activits des tapes 1,
2, 3, et 4 auront t effectues conformment aux critres tablis et que toutes les non
conformits majeures par rapport aux exigences dcrites et aux exigences GMP/BPF auront
t corriges :

Rfrence
CA-01

CA-02

CA-03

CA-04

Critres dacceptation du systme EXASCAN

Utilisation / exploitation du systme
Pour toutes les fonctions et processus critiques, une procdure ou un mode
opratoire approuv doit exister lors de la mise en production. En particulier
les points suivants doivent tre dcrits dans des procdures ou des documents
adquats :
Liste et description des fonctions (BPF, LDP 5, 4.), 21 CFR Part 11, 11.10
(k) (1)
Mesure de scurit : scurit physique, scurit logique, plan de secours
(BPF, LDP 5, 4.)
Gestion des profils et des utilisateurs (BPF, LDP 5, 8.) 21 CFR Part 11,
11.10 (k) (1)
Gestion des modifications (BPF, LDP 5, 11.) 21 CFR Part 11, 11.10 (k)
(2)
Maintenance curative / prventive (BPF, LDP 5, 13.)
Sauvegarde / restauration des donnes (BPF, LDP 5, 14.)
Dure de rtention des donnes dfinie (BPF, LDP 5, 14.)
Enregistrement de toutes les dfaillances ou les arrts (BPF, LDP 5, 16.)
Gestion des anomalies (BPF, LDP 5, 17.)
La revue de la formation du personnel au systme ne doit pas comprendre de
non-conformit vis vis des exigences GMP, FDA et BPF et :
L'ensemble du personnel doit tre form au nouveau systme,
Le niveau de formation doit tre valu et estim comme tant satisfaisant
par un formateur form au systme et au domaine concern.
(BPF, LDP 5, 1) 21 CFR Part 11, 11.10 (i)
Anomalies QI/QO/QP
Le niveau de confiance obtenu lors des tests de qualification QI/QO/QP des
lments identifis comme critiques doit tre acceptable. Pour chacun des
lments toutes les non-conformits majeures vis--vis de la rglementation
pharmaceutique GMP FDA & BPF sont rsolues
Composants du systme
Les composants matriels et logiciels sont identifis et installs dans un cadre
appropri (BPF, LDP 5, 3. et 4.).

47

Rfrence
CA-05

Critres dacceptation du systme EXASCAN

Fonctionnalits du systme
Les fonctionnalits du systme permettent dassurer :
Le contrle sur la saisie des donnes (saisie de paramtres incorrects) (BPF,
LDP 5, 6.) 21 CFR Part 11, 11.10 (a)
La vrification des accs au systme : blocage, enregistrement des accs
non autoriss (BPF, LDP 5, 8.) 21 CFR Part 11, 11.10 (d), 11.10 (g)
La traabilit sur la modification des donnes critiques : identit, motif du
changement (LDP 5, 10.) 21 CFR Part 11, 11.10 (e)
Limpression des donnes lectroniques en vue dun audit (LDP 5, 12.)
21 CFR Part 11, 11.10 (b)

3.1.3 Niveau de risque du systme Exascan

Cette matrice rcapitule les risques potentiels vis vis des BPF/GMP associs au systme
Exascan. Les fonctions du systme tant relativement simples, une matrice avec 3 niveaux de
risque est construite puis associe aux diffrentes fonctions dExascan.
N
Description du risque
Niveau 1 : Risques avec consquences rglementaires et sur le produit (Produit
fini, article de conditionnement )
R1.1
Libration dun lot darticle de conditionnement non conforme
R1.2
Rupture de traabilit sur un lot darticles de conditionnement
Niveau 2 : Risques avec consquences rglementaires seules, sans consquence
directe sur les produits.
R2.1
Scurit et signature lectronique errone sur une fonction GMP
R2.2
Altration de lintgrit ou perte dinformation BPF/GMP
Articles
Fournisseurs
Articles de rfrence
Modles
Commentaires
Lots
Utilisateur
Rapports
R2.3
Pas denregistrement de formation
R2.4
Pas de procdures informatiques et procdures utilisateurs
R2.5
Pas de change control sur le systme
Niveau 3 : Risques sans consquence rglementaire ou sur le produit
R3.1
Mauvaise disponibilit, intgrit, scurit du systme

48

3.1.4 Matrice de qualification linstallation

Le tableau ci-dessous rcapitule les entits matrielles et logicielles composant le systme
informatis Exascan qui sont inclure dans la qualification l'installation.
N lment

Intitul de llment

E 100
E101
E102
E 200
E 300
E 400
E 500
E 600
E 601
E 602
E 603
E 604
E 700
E 701
E 702
E 703
E 800

Station de travail
Unit centrale
Moniteur
Systme dexploitation
Base de donnes
Logiciel Exascan
Logiciel Cristal Report
Scanner
Logiciel associ au scanner
Contrleur SCCI associ au scanner
Cordon du raccordement du scanner
Driver associ au scanner
imprimante
Logiciel associ limprimante
Driver associ limprimante
Cordon de raccordement limprimante
Systme de sauvegarde et de restauration

Critique
(O/N)
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O

49

3.1.5 Matrice de qualification oprationnelle

Le tableau suivant identifie les processus qualifier lors de la qualification
oprationnelle et la justification de cette qualification vis vis des risques identifis cidessus

Rfrence de la
fonction

Libell de la fonction
Donnes techniques

F0101
F0102
F0103
F0104

F0201
F0202

F0301

F0401

F0402

F0501

Ref risque

N/A

N/A

Grer les utilisateurs (crer, modifier,

supprimer, attribuer, supprimer un mot C
de passe)
Grer les articles (crer, modifier,
C
inactiver un article de la base de donnes
Grer les fournisseurs ( crer, modifier,
C
inactiver un fournisseur
Gestion des commentaires (cration
pralable de commentaires standards, C
modifications des commentaires)
C
Interface utilisateur
Accder au systme (contrler laccs au
C
systme)
Grer les droits daccs au systme
(attribution, modification et suppression C
de niveau d'accs)
N/A
Gestion des modles
Gestion des articles de rfrences
(cration, modification et suppression
C
des articles de rfrences, attribution et
modification des donnes de calibration).
N/A
Contrle des chantillons
Prparation du contrle (choix dun
article, saisie de donnes de lot dun
article, choix dun modle, acquisition C
de limage de lchantillon, signature de
larticle et calcul des diffrences).

R2.1
R2.2

Traitement
des
diffrences
(acceptation/refus
des
diffrences
dtectes, choix des commentaires,
modification
du
traitement
des
diffrences, fin du contrle)

R2.1
R2.2
R2.1 R2.2
R2.1
R2.2
R2.1 ; R2.4
R2.1 ; R2.4
R2.1 ; R2.4
N/A
R2.2

N/A
R1.1 , R1.2 ,
R2.2

R1.1 , R1.2 ,
R2.2
C

N/A
Edition dun rapport de contrle
Consultation des rapports et impression
des rapports (choix dun type de rapport
C
dition lcran dun rapport, impression
de ce rapport)

N/A
R1.1 , R1.2 ,
R2.2

50

Rfrence de la
fonction

Libell de la fonction

Ref risque

Cration dun rapport (cration dun type

R1.1 , R1.2 ,
C
de rapport paramtrable).
R2.2
N/A
N/A
Traabilit et gestion des enregistrements
Sauvegarde /restauration des
R2.1 ;R2.2 ;R3.
F0601
C
enregistrements
1

F0502

3.1.6 Matrice de qualification de performance (systmes et interfaces)

Rfrence de
lopration

Libell de lopration

PR01

Gestion des accs et des enregistrements

PR02

Gestion des articles de rfrence

PR03
PR04

Contrle dun chantillon

Traabilit des contrles effectus

C
C

PR05

Administration de lapplication

PR06

Formation des utilisateurs

Ref
risque
R2.4,
R2.5,
R3.1
R2.4,
R2.5
R2.4
R2.4
R2.4,
R2.5,
R3.1
R2.3

51

3.2 Qualification linstallation Exascan v3.0

Lobjectif de la QI est de vrifier de manire documente que tous les points-cls
relatifs linstallation des matriels informatiques sont en conformit avec les normes et les
exigences de conception approuves et que les recommandations des fournisseurs ont t
appliques de manire adquate.

3.2.1 Protocole de Qualification linstallation

3.2.1.1 Objectifs
Lobjectif de ce protocole est de vrifier et dapporter les preuves documentes que
chaque lment logiciel et matriel du systme informatis Exascan V3.0 est install :
y

conformment ses spcifications et aux exigences rglementaires applicables,

sur le lieu prvu de son utilisation, dans un cadre appropri.

Ce protocole identifie les lments qualifier du systme et fait rfrence aux fiches dessais
qui prcisent les exigences respecter pour raliser cette qualification.
Il dcrit galement les critres dacceptation qui permettront de dterminer si lexcution des
fiches dessais est Satisfaisante, Satisfaisante sous Rserve ou Non Satisfaisante.
Les responsabilits sont les mmes que celles du plan de validation ainsi que les
documents de rfrences.

3.2.1.2 Codification des lments, des critres et des cas de tests

Les lments du systme sont codifis de la manire suivante : EXXX avec :

XXX = numro d'ordre d'identification de l'lment test

Les critres d'acceptation sont codifis de la manire suivante : CAQI## avec :

## = numro d'ordre d'identification du critre d'acceptation

Les fiches dessais sont codifies de la manire suivante : CTQIZZ-YY avec :

ZZ = numro d'ordre d'identification de llment test

YY = numro d'ordre d'identification dessai

52


3.2.1.3 Procdure de qualification linstallation
Les lments du systme dont linstallation est qualifier sont identifis dans les
fiches dessais. La fiche dessai est excute pour chaque lment. Il faut comparer
linstallation du systme aux exigences listes sur la fiche dessai, puis renseigner la colonne
CONFORMITE : avec un C lorsque lexigence est vrifie ; avec un NC lorsque lexigence
nest pas vrifie.
Le symbole  signifie quil est ncessaire de joindre une copie dcran au rsultat.
Le symbole  signifie quil est ncessaire de joindre un listing ou des ditions papiers au
rsultat
Le contrle est conforme si lexigence est vrifie. Lorsque lexigence nest pas vrifie, le
contrle est non conforme. Les anomalies sont releves et documentes conformment la
procdure de gestion des modifications et anomalies. Un vrificateur vrifie les rsultats du
tests laide des enregistrements joints aux fiches dessais et conclut sur la conformit de
lexcution ainsi que la conformit du test.

3.2.1.4 Spcification et conception des vrifications

Il sagit didentifier les critres dacceptation pour la qualification des composants qui ont t
dfinis dans le plan de validation.
Rf critre

Libell du critre dacceptation

N lment

Rf Risque couvert
par le critre (cf
plan de validation)

Installation / configuration
CAQI01

Tout lment est install conformment

ses spcifications

E100, E200,
E300, E400,
E500, E600

R1 ; R2 ; R3

CAQI02

Tout lment est install dans un cadre

appropri, de sorte que les facteurs
extrieurs ne puissent causer des
interfrences.

E101, E102,
E200, E300,
E600, E800

R3.1 ; R2

CAQI03

Linstallation de llment a t effectue

suivant une procdure et a donn lieu un
rapport dinstallation, de recette.

E100, E200,
E300, E400,
E500, E600,
E800

R2

53

Rf critre

CAQI04

Libell du critre dacceptation

N lment

Documentation des composants

La configuration de llment est E200, E300,
documente.
E400, E500,
E600, E800,

Rf Risque couvert par

le critre (cf plan de
validation)
R2.1 ; R2.2

CAQI05

La documentation de llment inclut une

description gnrale des oprations
informatises, des lments matriels et
logiciels de linfrastructure participant
cette informatisation.

E200, E400,
E500, E600,
E600, E800

R2.1 ; R2.2 ; R2.3 ; R2.4

CAQI06

La documentation
disponible et gre

E101, E102,
E200, E300,
E400, E500,
E600, E800

R3.1 ; R2

R1.1 ; R1.2

fournisseur

est

Maintenance
CAQI07

Les lments utiliss sont rgulirement

talonns,
vrifis
ou
contrls,
conformment un programme crit et
rfrenc.

E101, E200,
E300, E400,
E500, E600,
E800

CAQI08

Le personnel assurant la maintenance est

form.

Tous les
lments

CAQ09

En cas de maintenance assure par le

fournisseur, un contrat de maintenance
valide est disponible. En cas de
maintenance interne, une procdure de
maintenance approuve est applique.

E100, E200,
E300, E400,
E500, E600

R2

R3.1
R2

Matrise des volutions

CAQI10

Toute modification dun systme ou programme

informatis doit tre ralise conformment une
procdure dfinie prvoyant des dispositions
relatives la validation, au contrle,
lautorisation et la mise en uvre de la
modification. Cette modification ne peut tre
excute quavec lautorisation de la personne
responsable de la partie systme concerne et doit
tre enregistre. Toute modification importante
doit tre valide.

E101, E200,
E300, E400,
E500, E600,
E800

R1 ; R2

54

Rf critre

Libell du critre dacceptation

N lment

Rf Risque couvert
par le critre (cf
plan de validation)

CAQI11

Les lments importants ou essentiels sont

accompagns dun cahier de route
mentionnant, selon le cas, toutes les validations,
les talonnages, les oprations dentretien, de
nettoyage ou de rparation, avec les dates et le
nom des personnes ayant effectu ces oprations.

E101, E200,
E300, E400,
E500, E600,
E800

R2 ; R3.1 ; R1

Matrise des accs au systme

CAQI12

Laccs au systme est rgi par une procdure

approuve

E100, E200,
E300, E400,
E500, E601

R2 ; R3

CAQI13

La liste des personnes autorises accder au

systme ainsi que leurs droits est documente.
Cette liste est tenue jour.

E100, E200,
E300, E400,
E500, E601

R2 ; R3

CAQI14

Des protections physiques permettent de

restreindre laccs physique llment
hbergeant les donnes un personnel identifi et
qualifi. Ceci sapplique aussi aux tapes
dinstallation, de maintenance et darchivage.

E100, E600,
E800,

R2 ; R3

Sauvegarde /restauration
CAQI15

Les activits de sauvegarde / restauration sont E200, E300, R2

dcrites dans des procdures approuves. Les E400, E800,
E500
donnes sauvegardes sont places dans un lieu
sr.

CAQI16

Les donnes sauvegardes doivent tre stockes E200, E300, R2

aussi longtemps que ncessaire dans des E400, E800
emplacements spars et surs.
E500
Les enregistrements de production, de contrle E300, E400, R2
ou de distribution associs un lot de produit fini E800, E500
sont conservs pendant une priode de 10 ans

CAQI17

Continuit du service en cas de dfaillance

CAQI18

Les mesures de remplacement adquates

permettant le fonctionnement des systmes en
cas de panne doivent tre prvues. Le temps de
remplacement doit tre en rapport avec le degr
de criticit de la panne (par exemple : donnes
ncessaires un rappel disponibles rapidement).
Les procdures suivre en cas de dfaillance ou
d'arrt du systme doivent tre dfinies et
valides

E100, E200,
E300, E400,
E500, E600,
E602

R1 ; R2 ; R3

55

3.2.2 Fiches dessais

Le tableau ci dessous dfinit les vrifications pour chaque critre d'acceptation et chaque
composant. Les critres dacceptation sont regroups par cas de test et ces derniers par
lment.

Rf. cas

Description

FEQI_EXASCAN_01

Rf critre

Station de travail

CTQI01-01

Vrification de linstallation, de la
Configuration, et Contrle de llment et de
la Documentation.

CAQI01 CAQI02
CAQI03 CAQI06

CTQI01-02

Vrification
maintenance.

la

CAQI07 CAQI08
CAQI09 CAQI18

CTQI01-03

Vrification de la procdure de matrise des

modifications.

CAQI10 CAQI11

CTQI01-04

Vrification des procdures de matrise des

droits daccs.

CAQI12 CAQI13
CAQI14

de

FEQI_EXASCAN_02

lexploitation

et

Systme dExploitation

CTQI02-01

Vrification de linstallation, de la
Configuration, et Contrle de llment et de
la Documentation.

CAQI01 CAQI02
CAQI03 CAQI04
CAQI05 CAQI06

CTQI02-02

Vrification
maintenance

la

CAQI07 CAQI09
CAQI18

CTQI02-03

Vrification de la procdure de matrise des

modifications

CAQI10 CAQI11

CTQI02-04

Vrification des procdures de matrise des

droits daccs

CAQI12 CAQI13

CTQI02-05

Vrification des procdures de sauvegarde /

restauration

CAQI15 CAQI16

de

lexploitation

et

FEQI_EXASCAN_03

Base de donnes

CTQI03-01

Vrification de linstallation, de la CAQI01 CAQI02 CAQI03

Configuration, et Contrle de llment CAQI04 CAQI06 CAQI19
et de la Documentation.

CTQI03-02

Vrification de
maintenance

CTQI03-03

Vrification de la procdure de matrise

des modifications

CAQI10 CAQI11

CTQI03-04

Vrification des procdures de matrise

des droits daccs

CAQI12 CAQI13

CTQI03-05

Vrification
des
procdures
sauvegarde / restauration

lexploitation

et

la CAQI07 CAQI09 CAQI18

de CAQI15 CAQI16 CAQI17

56

Rf. cas

Description

FEQI_EXASCAN_04

Rf critre
Logiciels

CTQI04-01

Vrification de linstallation, de la
Configuration, et Contrle de llment et de
la Documentation.

CAQI01 CAQI03
CAQI04 CAQI05
CAQI06

CTQI04-02

Vrification
maintenance

la

CAQI07 CAQI09
CAQI18

CTQI04-03

Vrification des procdures de matrise des

droits daccs

CAQI12 CAQI13

CTQI04-04

Vrification des procdures de sauvegarde /

restauration

CAQI15 CAQI16
CAQI17

de

FEQI_EXASCAN_05

lexploitation

et

Scanner

CTQI05-01

Vrification de linstallation, de la
Configuration, et Contrle de llment et
Documentation.

CAQI01 CAQI02
CAQI03 CAQI06

CTQI05-02

Vrification
maintenance

CAQI07 CAQI09
CAQI18

CTQI05-03

Vrification des procdures de matrise des

droits daccs

de

FEQI_EXASCAN_06

lexploitation

et

la

CAQI13

Imprimante

CTQI06-01

Vrification de linstallation, de la
Configuration, et Contrle de llment et
Documentation.

CTQI06-02

Vrification
maintenance

la

CAQI07 CAQI09

CTQI06-03

Vrification des procdures de matrise des

droits daccs

CAQI13 CAQI14

FEQI_EXASCAN_07

de

lexploitation

et

CAQI01 CAQI03
CAQI06

Systme de Sauvegarde et de Restauration

CTQI07-01

Vrification de linstallation, de la
Configuration, et Contrle de llment et la
Documentation

CAQI03 CAQI05

CTQI07-02

Vrification de la maintenance du systme de

sauvegarde et de la procdure de matrise des
modifications.

CAQI07 CAQI10

CTQI07-03

Vrification des procdures de matrise des

droits daccs.

CAQI13 CAQI14

CTQI07-04

Vrification des procdures de sauvegarde /

restauration.

CAQI15

57

3.2.3 Rapport de qualification linstallation

A lissue de lexcution de ces Fiches dessais, un rapport de conclusion de QI est
rdig. Ce rapport dcrit les rsultats obtenus lors de l'excution du protocole de QI, lanalyse
des non-conformits et le rsultat final du protocole.
3.2.3.1 Bilan des rsultats

Rf fiche dessai

Description

N
Ex

C/NC

N Fiche anomalie

FEQI_EXASCAN_01 Vrification de la maintenance du

composant

NC

FAQI_EXASCAN_01

FEQI_EXASCAN_04 Vrification de lexploitation et de la

maintenance du composant

NC

FAQI_EXASCAN_02

FEQI_EXASCAN_05 Vrification de lexploitation et de la

maintenance du composant

NC

FAQI_EXASCAN_03

3.2.3.2 Bilans des anomalies enregistres

N Fiche
Description de
tat
Consquence Criticit
Actions mettre en
anomalie
l'anomalie
uvre
du 2
Avertir
le
service
FAQI_EXASCAN Il
nexiste En cours Drive
systme
informatique Roche afin
_01
aucune
quil puisse prendre en
maintenance de
charge la maintenance
la station de
informatique
des
travail
composants matriels et
logiciels dExascan
du 2
1) Voir si le logiciel est
FAQI_EXASCAN Il nexiste pas de En cours Drive
systme
toujours disponible et
_02
contrat
de
maintenu chez un
maintenance
autre fournisseur
pour le Logiciel
2) Maintenance
par
Exascan
linformatique
si
possible
3) En cas de problme
critique non rsolu,
remplacement
du
systme

58

N Fiche
Description de
tat
Consquence
anomalie
l'anomalie
FAQI_EXASCAN Il nexiste pas de En cours Maintenance
errone
_03
contrat
de
maintenance
pour le Scanner
GT 12000

Criticit
2

Actions mettre en
uvre
Avertir
le
service
informatique afin quil
puisse prendre en charge
la
maintenance
informatique du scanner
dExascan

Criticit :1 Anomalie Critique : impact sur la qualit du produit entranant un risque pour la
sant publique Anomalie bloquante
Criticit :2 Anomalie Majeure : Sans impact direct sur la qualit du produit mais avec un cart
rglementaire (BPF/GMP)
Criticit :3 Anomalie Mineure : hors GMP, impact sur processus industriel, excution errone
des tests (donnes errones, tapes errones)
3.2.3.3 Conclusion du rapport de QI
Lexcution de la QI est accepte sous rserve de la ralisation des actions correctives
nonces dans les paragraphes ci-dessus.
Toutes les actions correctives qui ont t mises en place ont permis de pallier aux diffrentes
anomalies, la QI est donc approuve par lassurance qualit.

59

3.3 Qualification operationnelle Exascan v3.0

La QO consiste vrifier de manire documente que le systme et ses quipements
connects fonctionnent tel que demand lintrieur des limites prvues ou reprsentatives,
dans les conditions les plus proches possibles des futures conditions relles de production.

3.3.1 Protocole de qualification oprationnelle

3.3.1.1 Objectifs
Lobjectif de ce protocole est la qualification oprationnelle du systme Exascan V3.0
Il dcrit :

le systme test et lenvironnement de validation,

le domaine test,

la procdure de test,

la spcification des tests (critres dacceptation, cas de test),

la conception des tests (dcoupage en fiches dessai, donnes de test).

Les responsabilits sont les mmes que celles de la QI. Les documents de rfrences utiliss
sont ceux du plan de validation, en plus du rapport de QI.
3.3.1.2 Codification des fonctions, des critres, des donnes de tests, et des fiches dessais
Les fonctions du systme sont codifies de la manire suivante : FUUXX avec :

UU = numro d'ordre didentification du domaine de la fonction teste.

XX = numro d'ordre d'identification de la fonction teste

Les critres d'acceptation sont codifis de la manire suivante : CAQO## avec :

## = numro d'ordre du critre dacceptation

Les cas de tests sont codifis de la manire suivante : CTQOZZZZ-YY avec :

ZZZZ= le numro dordre didentification de la fonction teste

YY= numro dordre didentification du cas de test.

60

3.3.1.3 Procdure de qualification oprationnelle

Lexcution des tests ne peut tre engage tant que toutes les conditions relatives
lenvironnement de qualification nont pas t vrifies. Lensemble de ces conditions (pr
requis) est formalis dans les fiches dessai.
Il sagit de vrifier que :

lenvironnement dexcution de la qualification est correctement dfini et install,

tous les lments documentaires, matriels, logiciels et organisationnels ncessaires

lexcution de la qualification sont prsents,

les donnes de tests ncessaires lexcution des tests sont prsentes dans la base de
donnes de lenvironnement de qualification (QO).
Il faut tester les diffrentes fonctionnalits du systme, ses limites, ses capacits, ses

performances, sa sauvegarde, sa maintenance conformment aux exigences listes sur la fiche

dessai, puis renseigner la colonne CONFORMITE : avec un C lorsque lexigence est
vrifie ; avec un NC lorsque lexigence nest pas vrifie.
Le symbole  signifie quil est ncessaire de joindre une copie dcran au rsultat. Le
symbole  signifie quil est ncessaire de joindre un listing ou des ditions papiers au
rsultat. Le contrle est conforme si lexigence est vrifie. Lorsque lexigence nest pas
vrifie, le contrle est non conforme. Les anomalies sont releves et documentes
conformment la procdure de gestion des modifications et anomalies. Un vrificateur
vrifie les rsultats du test laide des enregistrements joints aux fiches dessais et conclut sur
la conformit de lexcution ainsi que la conformit du test.
3.3.1.4 Spcification des tests
Il sagit de dfinir les fonctions et donnes tester et didentifier les critres dacceptation du
domaine.

Donnes techniques

Interface utilisateur

Gestion des modles

Contrle des chantillons

Edition de rapports de contrle

Traabilit et gestion des enregistrements

61

3.3.1.4.1 Fonctions
Le domaine se compose des fonctions dfinies dans le tableau ci-dessous.
N

TITRE DE LA FONCTION

FONCTION

CRITIQUE (O/N)

F0101

Grer les utilisateurs

F0102

Grer les articles

F0103

Grer les fournisseurs

F0104

Grer les commentaires

F0201

Grer les droits daccs

F0302

Grer les articles de rfrence

F0401

Prparer le contrle

F0402

Traiter les diffrences

Consulter les rapports et les impressions des
rapports
Crer des rapports
Sauvegarder,
restaurer
et
archiver
des
enregistrements

F0501
F0502
F0601

O
O
O

3.3.1.4.2 Donnes
Le tableau ci-dessous prsente les donnes manipules ou prsentes dans le processus
considr. Pour chaque donne la criticit est mentionne

LIBELLE DE LA DONNEE

CRITIQUE

(O/N)

JUSTIFICATION / COMMENTAIRE

Fonction F0101 Grer les utilisateurs

Nom

Prnom

Mot de passe

Type de droits

Validit

Perte de la traabilit sur la gestion

profils.
Pas daccs une transaction devant
autorise.
Accs une autorisation critique
autorise.
Perte de traabilit sur la gestion
autorisations.

des
tre
non
des

Fonction F0102 Grer les articles

62

LIBELLE DE LA DONNEE

CRITIQUE

(O/N)

Rfrence

Nombre de face(s)

Nombre de pose(s)

Fournisseur

Validit

Date de cration

Date de modification

Etat de la modlisation

Etat de la calibration

JUSTIFICATION / COMMENTAIRE

Perte de traabilit.
Perte de donnes.
Absence de contrles sur cet article.
Libration de lots non contrls.

Fonction F0103 Grer les fournisseurs

Socit

Suivi erron, perte de traabilit

Adresse 1

Pas de gestion par Exascan.

Adresse 2

Pas de gestion par Exascan.

Code postal

Pas de gestion par Exascan.

Ville

Pas de gestion par Exascan.

Tlphone

Tlcopie

Pas dinfluence sur lidentification du

fournisseur
Pas dinfluence sur lidentification du
fournisseur

Fonction F0104 Grer les commentaires

Libell du commentaire

Perte des traabilits des non conformits

Fonction F0201 Grer les droits daccs

Nom utilisateur

Prnom utilisateur

Mot de passe

Type de droits

Validit

Perte de traabilit sur la gestion des

profils
Accs aux transactions critiques dun
profil non activ
Pas daccs aux transactions composant le
profil

Fonction F0302 Grer les articles de rfrence

63

LIBELLE DE LA DONNEE

CRITIQUE

(O/N)

Couleur du fond

Type du modle AC

Rfrence

Signature, croix 1

Signature, croix 2

Identification, n de face

Identification, n de pose

Calibration, sensibilit

Calibration, contraste

Etat de la calibration

Etat de la modlisation

Nombre de face(s) calibre(s)

Nombre de face(s) modlise(s)

Date de cration du modle

JUSTIFICATION / COMMENTAIRE

Modlisation errone
Libration de lots non conformes

Fonction F0401 Prparer le contrle

Validit

Etat de la modlisation

Etat de la calibration

Rfrence

Nombre de face(s)

Nombre de pose(s)

Fournisseur

Identification, n de lot interne (n SAP)

Identification, n de lot externe (n de lot

fournisseur)

Identification, n de pose

Signature, croix 1

Signature, croix 2

Couleur du feu tricolore

Nom du modle choisi

Type du modle choisi

Refus dun lot conforme

Diffrences errones

Fonction F0402 Traiter les diffrences

64

LIBELLE DE LA DONNEE

CRITIQUE

(O/N)

Rfrence

Fournisseur

Identification, n de lot interne (n SAP)

Identification, n de lot externe (n de lot

fournisseur)

Identification, n de pose

Identification, n de face

Nombre total de diffrences

Nombre de diffrences visualises

Nombre de nouvelles diffrences

N de la diffrence

Type de dfaut (= commentaire)

Nombre de face(s)

Nombre de face contrle

Couleur du feu tricolore

Nombre de dfauts

JUSTIFICATION / COMMENTAIRE

Refus dun lot conforme

Diffrences errones
Acceptation dun lot non conforme
Perte des traabilits des non conformits
Modlisation errone
Libration de lots non conformes
Perte de traabilit de donnes
Perte de donnes brutes

Fonction F0501 Consulter les rapports et les impressions des rapports

Nom du rapport

Choix du rapport (prdfini ou non)

Type de rapport (journalier, lot danalyse,

paramtrable, personnalis)

Edition cran

Pas dinfluence sur la qualit du contrle

Impression papier

Traabilit

Traabilit
Traabilit

Fonction F0502 Crer des rapports

Type de rapport (journalier, lot danalyse,
paramtrable, personnalis)

Traabilit

Fonction F0601 Sauvegarder, restaurer et archiver des enregistrements

Chemin daccs de la base de donnes

Chemin daccs aux Types de rapport

(journalier, lot danalyse, paramtrable,
personnalis)

Numro de face du modle

Numro de pose du modle

Traabilit

65

3.3.1.4.3 Risques
Les risques lis au prsent protocole sont les suivants
N
N Risque Description du Risque
Fonction
F0101

RQO01-01

F0101

RQO01-02

F0102

RQO02-01

F0102

RQO02-02

F0103

RQO03-01

F0104

RQO04-01

F0201

RQO05-01

F0201

RQO05-02

F0302

RQO07-01

F0302

RQO07-02

F0401

RQO08-01

F0402

RQO09-01

F0402

RQO09-02

F0402

RQO09-03

F0402

RQO09-04

F0502

RQO10-01

F0402

RQO09-04

F0502

RQO10-01

Consquence de la dfaillance

Cration / modification errone dun Perte de traabilit sur la gestion

utilisateur
des profils
Activation / dsactivation dun Pas daccs une transaction
utilisateur errone
devant tre autorise
Accs une transaction critique
non autorise
Perte de la traabilit sur la
gestion des autorisations
Cration darticles redondants
Perte de traabilit
Perte de donnes
Absence de contrles sur cet
Inactivation darticles valides
article
Libration de lots non contrls
Identification
errone
dun Suivi fournisseur erron
fournisseur
Perte de traabilit
Absence de commentaire associ un Perte de traabilit des non
dfaut
conformits
Cration / modification dune Utilisation
de
transactions
autorisation spcifique errone
critiques non autorises
Perte de traabilit sur la gestion
des autorisations
Affectation dautorisations un profil Pas daccs aux transactions
utilisateur erron
composant le profil
Accs aux transactions critiques
dun profil non activ
Perte de traabilit sur la gestion
des profils
Accepter un article erron comme Modlisation errone
rfrence
Libration de lots non conformes
Mauvaise signature dun article de Modlisation errone
rfrence
Libration de lots non conformes
Mauvaise signature dun chantillon
Refus dun lot conforme
Diffrences errones
Evaluation de la liste des dfauts Acceptation dun lot non
errone
conforme
Commentaires inappropris associs Perte de traabilit des non
des dfauts
conformits
Modlisation, signature ou calibration modlisation errone
incomplte
Libration de lots non conformes
Ecrasement des contrles effectus Perte de traabilit des donnes
sur les chantillons
Perte de donnes brutes
Ecrasement dun rapport prdfini par Perte de traabilit des donnes
un rapport personnalis
Perte de donnes brutes
Ecrasement des contrles effectus Perte de traabilit des donnes
sur les chantillons
Perte de donnes brutes
Ecrasement dun rapport prdfini par Perte de traabilit des donnes
un rapport personnalis
Perte de donnes brutes

66

N
N Risque Description du Risque
Fonction

Consquence de la dfaillance

Perte de la base de donnes

F0601

RQO11-01

F0601

RQO11-02

F0601

RQO11-03

F0601

RQO11-04

FO601

RQO11-05

F0601

RQO11-06

F0601

RQO11-07

Perte des modlisations

Perte de la traabilit des
donnes
Perte de donnes brutes
Perte des rapports
Perte de traabilit des donnes
brutes
Perte des modles
Libration de lots non contrls
Libration de lots compars sur
la base dune autre rfrence
Perte des fichiers images
Perte de traabilit des donnes
de rfrence
Perte de donnes brutes
Dgradation des donnes archives
Perte des donnes brutes
Impossibilit de restauration des Perte de traabilit des donnes
donnes archives
Perte daccs aux rpertoires critiques Perte de traabilit des donnes
Modifications / perte dintgrit des Perte de traabilit des donnes
rpertoires critiques
Perte de lintgrit des donnes

3.3.1.4.4 Critres dacceptation

Les critres dacceptation des diffrentes fonctions sont les suivantes.
Rf
critre
CAQO01

Libell du critre
N fonction
dacceptation
Toutes les donnes critiques doivent tre vrifies F0101 F0102
par le systme
F0103 F0104
F0201 F0302
F0401

CAQO02

Seules les personnes autorises peuvent effectuer F0101

des oprations critiques
F0102 F0201
F0302 F0402
F0502

CAQO03

Aucune donne critique ne doit disparatre du F0101 F0102

systme
F0103 F0104
F0302
F0502 F0601
F0602

CAQO04

Lidentit de la personne effectuant une cration de F0101 F0102

donne critique, la date ainsi que la donne F0103 F0104
concerne, sont enregistres
F0302 F0402
F0502
F0601

Rf risque
RQO01-01
RQO02-01
RQO03-01
RQO04-01
RQO05-02
RQO07-01
RQO01-01
RQO01-02
RQO05-01
RQO07-01
RQO09-02
RQO01-02
RQO02-02
RQO11-01
RQO11-02
RQO11-03
RQO11-04
RQO11-05
RQO11-07
RQO01-01
RQO02-01
RQO07-02
RQO09-02
RQO10-01

67

Rf
critre
CAQO05

CAQO06

CAQO07
CAQO08
CAQO09

CAQO10
CAQO11
CAQO12
CAQO13
CAQO14
CAQO15
CAQO16
CAQO17

CAQO18
CAQO19
CAQO20
CAQO21
CAQO22

Libell du critre
N fonction
dacceptation
Lidentit de la personne effectuant la modification F0101 F0102
ou la suppression dune donne critique, la date F0103 F0104
ainsi que les donnes concernes, sont enregistres F0302 F0401
F0402
F0601

Rf risque

RQO01-01
RQO02-02
RQO05-01
RQO06-01
RQO11-01
RQO11-02
RQO11-03
RQO11-04
RQO11-05
Les ditions (cran ou papier) sont restitues de F0102
RQO02-01
faon complte et exacte par le systme
F0104 F0302 RQO04-01
F0402 F0501
RQO07-01
F0502
RQO09-01
RQO11-02
Le systme nautorise pas lcrasement dun F0502
RQO10-01
fichier critique dans les rpertoires de travail
Seuls les modles (articles de rfrences) F0302 F0401 RQO07-01
totalement modliss puis calibrs, sont F0402
visualisables pour le contrle des lots.
Chaque modle est dfini par :
F0302
RQO11-03
Le numro darticle de larticle rfrence
Le numro de face de larticle rfrence
Le numro de pose de larticle rfrence
Tout utilisateur est identifiable de manire unique F0101 F0201
RQO01-01
Tout utilisateur doit se voir attribuer un type de F0101
RQO01-01
droit correspondant sa fonction.
RQO01-02
Seul un administrateur peut crer, modifier ou F0101 F0201
RQO01-01
supprimer (invalider) un utilisateur.
RQO01-02
Seul un administrateur ou un superviseur peuvent F0102 F0201
RQO02-01
crer et modifier un article.
Seul un administrateur peut supprimer un article
F0102
RQO02-02
F0201
Seul un administrateur ou un superviseur peuvent F0201 F0302 RQO07-01
modliser un article de rfrence (= crer un
RQO07-02
modle)
Seul un administrateur ou un superviseur peuvent F0201 F0302
RQO07-01
modifier un modle
F0401 F0402
RQO09-02
Un contrle doit tre dfini par :
RQO11-04
lutilisateur qui la effectu
le numro de pose de larticle prlev
le fournisseur de larticle prlev
les numros de lot externe et interne
la date de contrle
Tout commentaire associ un dfaut est compos F0104 F0402
RQO04-01
dun libell
RQO09-02
Toutes les faces dun article doivent tre contrles F0401 F0402
RQO07-01
avant le passage un article suivant
RQO07-02
Seul un administrateur ou un superviseur peuvent F0201 F0302 RQO05-01
rgler le contraste et la sensibilit de la calibration
RQO09-03
Il est possible de modifier les modles associs F0302
RQO09-03
un article de rfrence qui na pas servi effectuer
de contrle
Seul un administrateur ou un superviseur peuvent F0201 F0302
RQO08-01
annuler la signature dun nouveau modle

68

Rf
critre
CAQO23
CAQO24

CAQO25

CAQO26
CAQO27
CAQO28
CAQO29
CAQO30
CAQO31
CAQO32
CAQO33
CAQO34
CAQO35
CAQO36
CAQO37

Libell du critre
dacceptation
Lidentification dun nouveau modle nest
possible quaprs la signature de ce modle
Le nom du fichier image associ au modle de type
AC comprend :
la rfrence de larticle
le numro de face
le numro de pose
les lettres AC
une extension .jpg
Le nom du fichier configuration associ au modle
comprend :
la rfrence de larticle
le numro de face
le numro de pose
une extension AC
Seul un modle configur permet lacquisition
dun chantillon.
La signature dun chantillon doit tre la plus
fidle possible celle du modle

N fonction
F0302
F0302

RQO07-02
RQO09-03
RQO11-04

F0302

RQO11-03

F0401

RQO09-03

F0401

RQO07-02
RQO08-01
RQO09-03
RQO09-03

Lannulation de la signature dun chantillon est F0401

possible
Tout dfaut doit avoir un commentaire associ
F0402
Lensemble des diffrences identifies par le
systme par rapport au modle est enregistr par le
systme.
Il est possible de reprendre linterprtation des
diffrences enregistres par le systme, lissue
dune comparaison.
Un contrle est complet une fois que toutes les
faces dun article ont t contrles
Seul un modle de type AC peut servir de
rfrence pour un contrle
Seul un administrateur ou un superviseur peuvent
crer un modle AC
La restauration des donnes archives est ralise
sans perte de lintgrit des donnes
La restauration des donnes aprs sauvegarde est
ralise sans perte de lintgrit de celles ci
La restauration des donnes archives est ralise
sans perte de lintgrit des donnes

Rf risque

F0402

RQO04-01
RQO09-02
RQO09-04

F0402

RQO09-04

F0401 F0402

RQO09-03

F0401

RQO09-04

F0201

RQO09-03

F0601

RQO11-05

F0601

RQO11-05
RQO11-06
RQO11-05

F0601

69

3.3.1.5 Conception des tests

Lobjectif de cette tape est de dfinir :
les cas de tests ncessaires la dmonstration de conformit du systme aux critres
dacceptation
les donnes de tests.
3.3.1.5.1 Cas de test
N Fonction

Titre de la fonction

Rf cas

Type de
test

F0101

Rf critre

Crer des utilisateurs

CTQO01-01

CTQO01-02

CTQO01-03

CTQO01-04

CTQO02-01

CTQO02-02

CTQO03-01

CTQO03-02

CTQO04-01

CTQO04-02

CTQO05-01

F0101
CTQO06-01

F0102
CTQO08-01

Description du critre dacceptation

Tentative de cration dun utilisateur sans un profil CAQO01

administrateur.
CAQO02
CAQO04
CAQO12
Tentative de cration dun utilisateur dj existant.
CAQO01
CAQO10
Tentative de cration dun utilisateur avec des CAQO01
paramtres errons
CAQO10
Test de cration dun oprateur et dun superviseur. CAQO01
Modifier des utilisateurs
Tentative de cration dun utilisateur existant par CAQO01
une modification.
CAQO10
Tentative de modification dun utilisateur par CAQO01
suppression de lidentifiant.
CAQO10
Supprimer des utilisateurs
Test de suppression dun utilisateur, et vrification CAQO01
de la conservation des contrles associs cet CAQO03
utilisateur.
CAQO05
Test de ltat de la validit dun utilisateur aprs CAQO01
invalidation.
CAQO03
Modifier un mot de passe
Tentative dattribution dun mot de passe existant CAQO01
(absence de redondance entre utilisateurs diffrents). CAQO10
Test aux limites dattribution dun mot de passe CAQO01
utilisateur
CAQO10
Modifier les droits dun utilisateur
Tentative dattribution dun type de droit non
dfini
Modifier la validit dun utilisateur
Tentative dattribution dune validit non dfinie
un utilisateur

CAQO01
CAQO11
CAQO01
CAQO02
CAQO05

Crer un article
Tentative de cration dun article avec un profil CAQO02
oprateur.
CAQO04
CAQO13

70

N Fonction

Titre de la fonction

CTQO08-02

Type de
test
D

CTQO08-03

CTQO08-04

CTQO09-01

CTQO09-02

CTQO10-01

CTQO10-02

CTQO10-03

CTQO11-01

CTQO11-02

F0103
CTQO12-01

CTQO12-02

Rf cas

CTQO13-01

CTQO13-02

CTQO14-01

CTQO14-02

F0104
CTQO15-01

CTQO16-01

Description du critre dacceptation

Rf critre

Tentative de cration dun article avec des donnes

errones
Tentative de cration dune rfrence existante
impossible.
Tentative de cration dun article dont le fournisseur
nexiste pas dans la base.
Ouvrir un article
Test de laffichage des donnes dun article aprs sa
cration et sa modification.
Tentative de modification des donnes dun article
Modifier un article
Tentative de modification dun article dont le
fournisseur nexiste pas.
Tentative de modification des modles dun article
ayant t utilis pour effectuer des contrles.
Vrification de la conservation des enregistrements
des contrles raliss avec un article invalid.
Inactiver un article
Tentative dinactivation dun article sans un profil
administrateur.

CAQO01
CAQO01
CAQO01
CAQO01
CAQO06
CAQO01
CAQO01
CAQO01
CAQO01
CAQO03

CAQO01
CAQO14
CAQO05
Tentative dattribution dune validit non dfinie CAQO01
un article.
CAQO03
Crer un fournisseur
Test aux limites de cration dun fournisseur.
CAQO01
CAQO04
Tentative de cration dun fournisseur avec un CAQO01
couple raison sociale / ville dj existant.
Modifier un fournisseur
Test aux limites de modification dun fournisseur.

CAQO01
CAQO05
Tentative de modification dun fournisseur avec un CAQO01
couple raison sociale/ville dj existant.
Supprimer un fournisseur
Test de suppression dun fournisseur.

CAQO03
CAQO05
Test de vrification de la conservation des donnes CAQO03
d'un fournisseur supprim.
CAQO01
Crer un commentaire
Test de saisie dun commentaire.
CAQO01
CAQO04
CAQO18

Modifier un commentaire
Test de modification dun commentaire.

CAQO01
CAQO03
CAQO05
CAQO06
CAQO18

Supprimer un commentaire

71

N Fonction

Titre de la fonction

CTQO17-01

Type de
test
D

CTQO17-02

F0201
CTQO18-01

CTQO18-02

CTQO18-03

CTQO18-04

CTQO18-05

CTQO18-06

CTQO18-07

CTQO18-08

F0302
CTQO20-01

CTQO20-02

CTQO20-03

CTQO20-04

CTQO20-05

CTQO20-06

F0401
CTQO21-01

Rf cas

Description du critre dacceptation

Rf critre

Tentative de suppression dun commentaire.

CAQO03
CAQO05
Test de vrification de la conservation des donnes CAQO01
associes un commentaire supprim.
CAQO03
Accder au systme
Tentative daccs au systme par un utilisateur CAQO01
inexistant dans le systme.
CAQO02
Tentative de connexion dun utilisateur sans la saisie CAQO01
dun mot de passe.
Tentative daccs au systme avec un couple CAQO01
identifiant / mot de passe erron.
CAQO10
Test de vrification des droits utilisateurs.
CAQO01
CAQO12
CAQO13
CAQO14
Tentative daccs au systme par un utilisateur CAQO01
invalide.
CAQO02
Tentative de modlisation dun article de rfrence CAQO01
par un oprateur.
CAQO02
CAQO15
CAQO34
Tentative de rglage de la calibration dun article de CAQO01
rfrence par un oprateur lors dun contrle.
CAQO02
CAQO20
Tentative dannulation de la signature dun nouveau CAQO01
modle par un oprateur.
CAQO02
CAQO22
Grer les articles de rfrence
Tentative de modlisation ou de modification dun CAQO02
article de rfrence par un oprateur.
CAQO04
CAQO05
CAQO15
CAQO16
Tentative de rglage de la calibration dun article de CAQO02
rfrence par un oprateur.
CAQO20
Tentative dannulation de la signature dun modle CAQO01
par un oprateur.
CAQO02
CAQO22
Tentative de modification des modles associs un CAQO21
article de rfrence dj utilis pour effectuer des
contrles.
Test de vrification de la composition de CAQO09
lidentification du modle (nom fichier), du fichier CAQO24
de configuration, et des fichiers image (AC).
CAQO25
Test de validation dune opration de comparaison CAQO03
lors de la survenue dune coupure alimentation.
Prparer le contrle
Tentative de contrle de lot avec un article de CAQO01
CAQO08
rfrence :
CAQO33
non-valide
partiellement modlis
partiellement calibr.

72

N Fonction
Rf cas
CTQO21-02

CTQO21-03
CTQO21-04
CTQO21-05
F0402
CTQO22-01
CTQO22-02
CTQO22-03
CTQO22-04
CTQO22-05
F0501
CTQO23-01
F0502
CTQO24-01

CTQO24-02
F0601
CTQO25-01

CTQO25-02
CTQO25-03
CTQO25-04

CTQO25-05

CTQO25-06

Titre de la fonction
Type de
test
N

Description du critre dacceptation

Rf critre

Test de vrification de la composition de la CAQO17

dfinition du contrle.
CAQO02
CAQO04
CAQO05
D
Tentative de contrle avec un modle non configur. CAQO01
CAQO26
L
Tentative de signature avec deux croix trs CAQO27
loignes de la position de celles du modle.
N
Test dannulation de la signature dun chantillon.
CAQO28
CAQO05
Traiter les diffrences
D
Tentative de caractrisation dun dfaut sans saisie CAQO18
de commentaire.
CAQO29
D
Tentative de contrle dun article, avant la fin du CAQO19
contrle de toutes les faces de larticle prcdent.
D
Test de vrification de la seule prise en compte des CAQO30
dfauts dfinis aprs interprtation de toutes les
diffrences.
N
Test de reprise de linterprtation des diffrences CAQO31
enregistres par le systme, lissue dune
comparaison.
D
Tentative de clture dun contrle avant la fin du CAQO01
contrle de toutes les faces de larticle.
CAQO32
Consulter et imprimer un rapport
N
Test de vrification de la restitution cran du rapport CAQO06
et de limpression papier des contrles raliss.
Crer un rapport
D
Tentative de cration de rapport personnalis avec CAQO02
un nom dj existant.
CAQO03
CAQO04
CAQO07
S
Test de coupure alimentation lors de limpression CAQO03
dun rapport de contrle.
CAQO06
Sauvegarder, restaurer et archiver des enregistrements
N
Test de vrification du chemin daccs la base de CAQO03
donnes (.mdb), ainsi quaux types de rapports
(journalier,
lot
danalyse,
paramtrable,
personnalis).
N
Test de vrification du chemin daccs au modle ( CAQO03
type AC), ainsi quaux fichiers de configuration
(signatures des modles) (AC).
N
Test de vrification du chemin daccs aux fichiers CAQO03
images des modles et des chantillons (.jpg).
N
Test de la sauvegarde des donnes des modles, et CAQO02
des contrles dun lot
CAQO03
CAQO04
CAQO05
N
Test de restauration des donnes sauvegardes de CAQO03
modles et de contrles de lots, et vrification de CAQO35
lintgrit des donnes restaures.
CAQO36
CAQO37
N
Test de vrification de lintgrit des donnes CAQO03
archives de modles et de contrles de lots.

73

1 N=

nominal : test effectu dans les conditions normales

D= dfaillant : test effectu en utilisant des valeurs errones
L= limite : test effectu en utilisant des rfrences minimales et maximales errones
S= stress : test effectu en nominal, bas sur la rapidit daction et le dlai de rponse

3.3.2 Fiches dessais

Le tableau suivant dcrit lenchanement de cas de tests par fiche dessai.
Rf Fiche
FEQO_EXASCAN_01

FEQO_EXASCAN_02

FEQO_EXASCAN_03
FEQO_EXASCAN_04
FEQO_EXASCAN_05
FEQO_EXASCAN_06
FEQO_EXASCAN_07
FEQO_EXASCAN_08
FEQO_EXASCAN_09
FEQO_EXASCAN_10

Libell fiche
Grer les utilisateurs

Enchanement des cas de tests

CTQO01-04 CTQO01-01 CTQO01-02
CTQO01-03 CTQO02-01 CTQO02-02
CTQO03-01 CTQO03-02 CTQO04-01
CTQO04-02 CTQO05-01 CTQO06-01
Grer les articles
CTQO08-01 CTQO08-02 CTQO08-03
CTQO08-04 CTQO09-01 CTQO09-02
CTQO10-01 CTQO10-02 CTQO10-03
CTQO11-01 CTQO11-02
Grer les fournisseurs
CTQO12-01 CTQO12-02 CTQO13-01
CTQO13-02 CTQO14-01 CTQO14-02
Grer les commentaires
CTQO15-01 CTQO16-01 CTQO17-01
CTQO17-02
Grer les droits daccs
CTQO18-01 CTQO18-02 CTQO18-03
CTQO18-04 CTQO18-05 CTQO18-06
CTQO18-07 CTQO18-08
Grer les articles de CTQO20-01 CTQO20-02 CTQO20-03
rfrence
CTQO20-04 CTQO20-05 CTQO20-06
Prparer le contrle
CTQO21-01 CTQO21-02 CTQO21-03
CTQO21-04 CTQO21-05 CTQO21-06
Traiter les diffrences
CTQO22-01 CTQO22-02 CTQO22-03
CTQO22-04 CTQO22-05
Crer un rapport, consulter CTQO23-01 CTQO24-01 CTQO24-02
les
rapports
et
les
impressions des rapports
Sauvegarder / restaurer des CTQO25-01 CTQO25-02 CTQO25-03
CTQO25-04 CTQO25-05 CTQO25-06
enregistrements
Archivage et restauration
des enregistrements

3.3.3 Rapport de qualification oprationnelle

A lissue de lexcution de ces Fiches dessais, un rapport de conclusion de QO est
rdig. Ce rapport dcrit les rsultats obtenus lors de l'excution du protocole de QO,
lanalyse des non-conformits et le rsultat final du protocole.

74

3.3.3.1 Bilan des rsultats des tests

Rf fiche dessai

Description

C/NC

N Fiche anomalie

Grer les utilisateurs

N
Ex
1

FEQO_EXASCAN_01

NC

FEQO_EXASCAN_02
FEQO_EXASCAN_03
FEQO_EXASCAN_04
FEQO_EXASCAN_05

Grer les articles

Grer les fournisseurs
Grer les commentaires
Grer les droits daccs

1
1
1
1

NC
NC
NC
C

FEQO_EXASCAN_06

Grer les articles de rfrence

FEQO_EXASCAN_07
FEQO_EXASCAN_08

Prparer le contrle
Traiter les diffrences

1
1

NC
C

FEQO_EXASCAN_09

Crer un rapport, consulter

rapports et les impressions
rapports
Sauvegarder / restaurer
enregistrements
Archivage et restauration
enregistrements

les 1
des

NC

FAQO_EXASCAN_02
FAQO_EXASCAN_03
FAQO_EXASCAN_04
FAQO_EXASCAN_01
FAQO_EXASCAN_05
FAQO_EXASCAN_06
Pas
danomalie
rencontre dans le cadre
de lexcution de cette
fiche dessai
Pas
danomalie
rencontre dans le cadre
de lexcution de cette
fiche dessai
FAQO_EXASCAN_07
Pas
danomalie
rencontre dans le cadre
de lexcution de cette
fiche dessai
FAQO_EXASCAN_08

des 1

FEQO_EXASCAN_10

des

Pas
danomalie
rencontre dans le cadre
de lexcution de cette
fiche dessai

75

3.3.3.2 Bilan des anomalies enregistres

N
Fiche
anomalie
FAQO_EXAS
CAN_01

FAQO_EXAS
CAN_02

FAQO_EXAS
CAN_03

FAQO_EXAS
CAN_04

Description
de
l'anomalie
Exascan accepte au
niveau de la case
rfrence
de
larticle :
des mots de 30 lettres
comme nombre de
pose : 35 ; 6 ; 1.109
comme nombre de
face : 35 ; 6 ; 1.109
Ce qui est aberrant.
Exascan accepte des
chiffres, des sigles ou
encore une lettre dans
la case Nom , lors de
la cration dun nouvel
utilisateur. Alors quen
thorie il est impossible
de rentrer des chiffres
la place du nom ou
encore le nom doit tre
compos de plus dune
lettre
Exascan accepte des
chiffres, des sigles ou
encore une lettre dans
le champ Mot de
passe , lors de la
cration dun nouvel
utilisateur. Alors quen
thorie il est impossible
de rentrer des chiffres,
des sigles ou encore
une lettre comme mot
de passe
Exascan naccepte pas
les caractres spciaux
suivants ! @ #
comme mot de passe
lors de la cration dun
nouvel
utilisateur.
Lorsquon modifie le
mot de passe dun
utilisateur
Exascan
accepte ces sigles, ce
qui est contradictoire

tat

Consquence

A
Utilisation
clturer errone
systme

Criticit Actions mettre en

uvre
2
Les rfrences des
du
ADC seront rentres tel
quil est indiqu sur la
procdure dutilisation
dExascan
IG DQ/CdQ 0025 L007
*A 0011

A
Perte
de 2
clturer traabilit
Gestion
des
profils errone

Exascan sera utilis par

quatre techniciens en
routine, les nouveaux
utilisateurs
seront
dfinis
par
un
administrateur.
Tout
utilisateur recevra une
formation adquate et
sera sensibilis. IG
DQ/CdQ B025 L007
*A 0011

A
Mot de passe 2
clturer facile trouver
Accs par une
personne non
autorise
Perte
de
traabilit

Idem
FEQO_EXASCAN_02

A
Perte
clturer traabilit

Exascan sera utilis par

quatre techniciens en
routine qui recevront
une
formation
au
pralable. Ces sigles
seront
exclus
des
diffrents mots de passe
choisis
par
les
techniciens.
IG
DQ/CdQ B025 L007
*A 0011

de 2

76

N
Fiche
anomalie
FAQO_EXAS
CAN_05

FAQO_EXAS
CAN_06

Description
de
l'anomalie
Exascan naccepte pas
les sigles ! @ #
lors de la cration dun
fournisseur. Lorsquon
modifie le fournisseur
Exascan accepte ces
sigles, ce qui est
contradictoire
La suppression dun
commentaire associ
un dfaut entrane sa
disparition sur tous les
rapports de contrle
effectus

tat

Consquence

Criticit Actions mettre en

uvre
A
Gestion
des 2
Ces sigles seront exclus
clturer fournisseurs
de la gestion des
errone
fournisseurs.
IG
DQ/CdQ B025 L007
*A 0011

A
Perte
de 2
clturer traabilit
Acceptation
dun lot non
conforme

FAQO_EXAS
CAN_07

Acceptation
2
Quand
on
signe A
lchantillon avec deux clturer dun lot non
conforme
croix trs loignes de
la position de celle du
modle, le contrle
indique zro diffrence
alors que lon aurait d
obtenir un trs grand
nombre de diffrence

FAQO_EXAS
CAN_08

Rapport
de 2
Arrt de limpression A
lors dune coupure clturer contrle erron
dalimentation
lectrique.
Pas
de
reprise de limpression
au mme niveau lors de
la
survenue
de
lalimentation
lectrique

Les utilisateurs seront

sensibiliss

la
procdure, IG DQ/CdQ
B025 L007 *A 0011.
Ils recevront en outre
une formation selon
cette procdure
Lors du contrle en
routine, les croix seront
trs proches de celles
du modle tel que le
recommande
le
fournisseur. Dans ces
conditions, le nombre
de
diffrence
est
acceptable. Tous les
utilisateurs
recevront
une formation adquate
IG DQ/CdQ B025
L007 *A 0011.
Rimpression
du
rapport

3.3.3.3 Conclusion
Lexcution de la QO est accepte sous rserve de la ralisation des actions correctives
nonces dans les paragraphes ci-dessus.
Toutes les actions correctives qui ont t mises en place ont permis de pallier aux diffrentes
anomalies, la QO est donc approuve par lassurance Qualit.

77

3.4 Qualification de performance Exascan v3.0

La QP consiste vrifier de manire documente que le procd et /ou avec son systme
intgr fonctionne tel que demand lintrieur des limites prvues

3.4.1 Protocole de qualification de Performance

3.4.1.1 Objectifs
Il sagit dapporter la preuve documente que le systme Exascan fonctionne de faon
correcte et rgulire dans son environnement de production.
Ce protocole dcrit :

Les exigences respecter

Les actions effectuer pour raliser cette qualification

Il dcrit galement les critres dacceptation qui permettront de dterminer si lexcution des
fiches dessai est Satisfaisante, Satisfaisante sous Rserve ou Non Satisfaisante.
Les responsabilits sont les mmes que celles de la QO, les documents de rfrences
utiliss
sont galement les mmes, en plus du rapport de QO.
3.4.1.2 Procdure de Qualification de Performance
La Qualification de performance comprend deux tapes :

Vrification avant suivi du service rgulier

Suivi du service rgulier du systme en exploitation

Le principe dexcution est le mme que celui de la QI et la QO

78

3.4.1.2.1 Vrification avant suivi du service rgulier

Cette vrification a pour but de sassurer que les tapes prcdentes de validation ont t
ralises conformment aux critres prtablis et de vrifier que :

La documentation relative au systme et son utilisation a t rdige, approuve et

diffuse,

Les utilisateurs sont qualifis et possdent le bon profil daccs,

Les donnes pharmaceutiques sont valides

Les actions correctives issues des prcdentes tapes de validation sont effectivement
mises en place.

3.4.1.2.1 Suivi du service rgulier

Cette tape consiste mettre en uvre une structure de surveillance accrue des
processus critiques du systme afin de vrifier le service rgulier en environnement rel de
production. Le suivi du service rgulier se droule sur une priode de un mois reprsentative
de lutilisation du systme.
Le suivi du service rgulier a pour objectif la vrification des objectifs identifis dans
le cahier des charges par la mise en place et le suivi dindicateurs sur lutilisation et
lexploitation du systme.

3.4.1.2 Spcification des tests

3.4.1.2.1 Vrification avant suivi du service rgulier
Les lments vrifis sont les suivants :

Les procdures dexploitation informatique (incluant les ventuelles actions correctives

organisationnelles lies des anomalies identifies en QI),

La rfrence aux rapports de QI et de QO

Les preuves de la formation des utilisateurs (supports de formation, enregistrements )

les preuves documentes de laffectation du bon profil daccs tous les utilisateurs

les preuves documentes de la validation des Articles de rfrence utiliss par le systme.

79

Les critres dacceptation de cette vrification avant suivi du service rgulier sont lists dans
le tableau suivant.
N du critre
Libell du critre dacceptation
CAQP-101
Tous les documents de dfinition du systme (cahier des
charges, spcification fonctionnelle, dossier de conception,
sont prsents, jour, et approuvs
CAQP-102
Toutes les procdures dexploitation informatique sont
prsentes, jour, approuves, diffuses, connues et appliques
CAQP-103
Tous les modes opratoires sont prsents, jour, approuvs,
diffuss, connus et utiliss
CAQP-104
Tous les utilisateurs ont reu une formation correspondant
leur utilisation du systme ; cette formation est enregistre et
value
CAQP-105
Les profils daccs sont attribus aux utilisateurs
conformment leur niveau dutilisation du systme
CAQP-106
Les Articles de rfrence utiliss dans le systme sont valids
par les personnes autorises
CAQP-107
Les actions correctives mettre en place suite lexcution de
la QI et de la QO sont effectivement mises en place

3.4.1.2.2 Suivi du service rgulier

Les processus pour lesquels sont mis en place des indicateurs de suivi de service rgulier sont
les suivants :
N Processus
PR01
PR02
PR03
PR04
PR05
PR06

Libell du processus
Gestion des accs et des enregistrements
Gestion des articles de rfrence
Contrle dun chantillon
Traabilit des contrles effectus
Administration de lapplication
Formation des utilisateurs

Les critres dacceptation associs ces processus sont les suivants :

N Critre
CAQP-201
CAQP-202
CAQP-203
CAQP-204

Libell du critre dacceptation

N Processus

Les profils dfinis ne sont pas modifis.

PR01
PR01
Seuls les utilisateurs autoriss et forms ont accs au PR06
systme.
Les modifications des articles de rfrence valids sont
documentes.
PR02
Les articles de rfrence utiliss dans le systme ainsi PR02
que les modifications apportes sont valids par les PR06
personnes autorises et formes.

80

N Critre
CAQP-205
CAQP-206
CAQP-207
CAQP-208
CAQP-209

CAQP-210
CAQP-211

Libell du critre dacceptation

Le nombre de dfauts dtects sur un mme chantillon
est constant.
Le nombre de diffrences dtectes qui ne
correspondent pas des dfauts est infrieur 20 par
contrle.
Le nombre de dfauts dtects autrement que par
Exascan et non dtects par Exascan est nul.
Tous les ajouts, et les modifications darticles de
rfrence et des comparaisons sont tracs.
Les donnes sont sauvegardes intervalles dfinis
(dans la procdure de sauvegarde). Les supports de
sauvegardes sont stocks dans des endroits spars et
srs dans le mme btiment.
La restauration naltre pas les donnes, et est effectue
par une personne autorise.
Les incidents dclars sur lapplication Exascan sont
documents et des actions correctives sont mises en
place.

N Processus
PR03
PR03
PR03
PR04
PR05

PR05
PR05

3.4.2 Fiches dessais

Les dtails des actions effectuer pour raliser les tests et les rsultats attendus associs sont
contenus dans les fiches de contrle suivantes :
Ref Fiche dessai

Libell de la fiche dessai

Ref Cas de test

Libell du cas de test

FEQP_EXASCAN_01

Fiche de Qualification de Performance Avant dmarrage

CTQP101

Vrification des documents de dfinition du systme

CTQP102

Vrification des procdures dexploitation informatique

CTQP103

Vrification des modes opratoires

CTQP104

Vrification de la formation des utilisateurs

CTQP105

Vrification des profils daccs au systme

CTQP106

Vrification des Articles de rfrence utiliss dans le systme

CTQP107
FEQP_EXASCAN_02

Vrification des actions correctives mettre en place suite lexcution

de la QI et de la QO
Fiche de Qualification de Performance en Suivi rgulier

CTQP201

Vrification de la modification des profils.

CTQP202

Vrification des utilisateurs du systme.

CTQP203

Vrification de la modification des articles de rfrence.

CTQP204

Vrification de la modification des articles de rfrence utiliss dans le

systme.

81

Ref Fiche dessai

Libell de la fiche dessai

Ref Cas de test

Libell du cas de test

CTQP205

Vrification du nombre de dfauts dtects sur un mme chantillon.

CTQP206
CTQP207

Vrification du nombre de diffrences dtectes qui ne correspondent pas

des dfauts.
Vrification du nombre de dfauts non dtects par Exascan

CTQP208

Vrification de la traabilit des modifications.

CTQP209

Vrification de la sauvegarde des donnes.

CTQP210

Vrification des restaurations de donnes.

CTQP211

Vrification des incidents dclars sur lapplication.

3.4.3 Rapport de qualification de Performance

A lissue de lexcution de ces Fiches dessais, un rapport de conclusion de QP est

rdig. Ce rapport dcrit les rsultats obtenus lors de l'excution du protocole de QP, lanalyse
des non-conformits et le rsultat final du protocole.
3.4.3.1 Bilans des rsultats des tests
Rf fiche dessai

Description

N Ex

C/NC

N Fiche anomalie

FEQP_EXASCAN Fiche de contrle avant dmarrage

_01

Pas
danomalie
rencontre dans le
cadre de lexcution de
cette fiche dessai

FEQP_EXASCAN Fiche de contrle suivi rgulier

_02

NC

FAQP_EXASCAN_01
FAQP_EXASCAN_02

82

3.4.3.1 Bilans des anomalies enregistres

N Fiche anomalie

Description de
tat
l'anomalie
FAQP_EXASCAN_ Exascan ralise A
01
la
suite
de clturer
plusieurs
contrles, plus de
20
diffrences
non considrs
comme
des
dfauts

Consquence

Criticit Actions mettre en

uvre
Les diffrences seront
Un grand nombre 2
interprtes une par
de diffrences
une , et pour chaque
interprter, ce qui
ADC, une validation
peut entraner un
est mise en uvre
manque
pour diminuer le
dattention sur un
nombre
de
vritable dfaut et
diffrences.
donc
IG DQ/CdQ B025
Libration dun
L007 *C 0020
lot non conforme.
Libration dun lot 1
Modification
du
FAQP_EXASCAN_ Le
systme A
Logiciel Exascan
02
Exascan
ne clturer non conforme.
dtecte pas des
diffrences sur
un
mme
chantillon, telles
que :
- les points des
i
- ou
encore
des chiffres

3.4.3.2 Conclusion

Suite lexcution de la QP, il sest rvl une anomalie bloquante pour laquelle une
action corrective doit tre mise en place pour rsoudre cette anomalie, avant toute poursuite
de la validation.
Laction corrective mettre en place est une modification du logiciel Exascan pour ce qui
concerne les tuis. Il savre que la socit commercialisant le logiciel Exascan nexiste plus
pour diverses raisons. Il est donc impossible dans limmdiat, sans aucune action corrective
de mettre en exploitation le systme Exascan pour le contrle des tuis. Lexcution de la QP
est donc refuse par LAssurance Qualit.
A Lissue de la QP, un rapport final de validation est rdig, il consiste faire une
synthse des rsultats des tches de validation effectues (rsultats obtenus lors des
qualifications), ce qui permet de conclure dfinitivement quant la validit du systme.

83

Activit

Conformit

Commentaire /
Anomalie

Rdaction du plan de validation

RAS

Rdaction du protocole et des

fiches dessais de QI

RAS

Rdaction du protocole et des

fiches dessais de QO

RAS

Rdaction du protocole et des

fiches dessais de QP

RAS

Excution de la QO

RAS

RAS

Excution
dmarrage

de

la

QP

avant

Excution de la QP suivi du
service rgulier

NC

Anomalie corriger

Rdaction du rapport final de

validation

NC

Anomalie corriger

Au vu de ces rsultats, (anomalie bloquante en QP), on considre la validation du systme

Exascan non satisfaisante par rapport aux risques pharmaceutiques encourus, pour ce qui
concerne le contrle des tuis. La mise en exploitation est donc reporte pour les tuis.

84

CONCLUSION

La validation des systmes informatiss est un sujet trs complexe. Quel que soit
l'organisme rglementaire dont elles manent, les recommandations en terme de validation
sont trs voisines et les objectifs sont identiques. Cependant, aucun organisme n'explique en
dtail comment valider un systme informatique et quel modle de documentation utiliser.
Le flou qui existe ce niveau profite certaines entreprises qui vendent des prix dor des
process de validation. La multiplicit et la diversit des applications existant aujourd'hui sur le
march empche d'mettre une documentation unique qui servirait de rfrentiel de
validation.
En prenant lexemple de la validation de lapplication Exascan, je vous ai prsent une
facette de la validation dun systme informatis. Cet exemple met en vidence la ncessit de
valider un tel systme. En effet pour un contrle plus fiable des tuis et des notices, et par
rapport lil humain, il tait indispensable de disposer dune application valide et fiable au
regard des autorits de sant. Les diffrentes tapes de la qualification ont permis datteindre
les objectifs fixs, la validation dExascan. Des actions correctives doivent y tre apportes
pour obtenir des rsultats satisfaisants sur le contrle des tuis.
La validation des systmes informatiss jugs critiques est indispensable; elle permet
au laboratoire, ainsi qu'aux inspecteurs, d'avoir pleinement confiance dans la qualit des
produits fabriqus car elle implique un procd bien connu et sous contrle. Cette dmarche
coteuse et contraignante doit tre vcue par tous comme un outil de progrs ncessaire et non
comme une contrainte rglementaire subir.
Afin de mener bien une validation d'un systme informatis, il est trs important de
s'appuyer sur une dmarche prcise, rigoureuse, mthodique et transparente. C'est chaque
entreprise de dfinir le niveau et la qualit de la validation apporter au projet informatique
suivant lexigence rglementaire auquel elle prtend. Il est ncessaire pour cela quelle puisse
se donner les moyens humains et financiers d'y parvenir car la validation est un exercice
continu qui demande du personnel qualifi et beaucoup de temps.

85

ANNEXE A

Base de donnes

Scanner

Station de travail

Imprimante

86

BIBLIOGRAPHIE
[1] AFSSAPS : Agence de scurit sanitaire des produits de sant
Bulletin officiel : Bonne Pratique Fabrication dition 1998
[2] Federal register Department of Health and Human Services FDA 21 CFR part 210
and 211 current Good Manufacturing Practice May 1996
[3] GMP Good Manufacturing Practices

Commission europenne Direction gnrale

industrie pharmaceutique et cosmtique dition 1999

[4] FDA : Food and Drug administration: Center for Drug Evaluation and Research
Guide to inspection of computerized systems used in the manufacture of drug producing- The
Bluebook fvrier 1983
[5] GAMP Forum (Good Automated Manufacturing Practice Forum)
GAMP GUIDE for Validation of Automated Systems in Pharmaceutical Manufacture,
December 2001
[6]. R.F. TETZLAFF
GMP Documentation Requirements for Automated Systems, Part l - Pharmaceutical
Technology, March 1992
[7]. R.F. TETZLAFF
GMP Documentation Requirements for Automated Systems, Part II - Pharmaceutical
Technology, April1992
[8]. R.F. TETZLAFF
GMP Documentation Requirements Part III - FDA Inspections of Computerized Laboratory
Systems Pharmaceutical Technology, April1992

87

[9] A.J TRILL

Computerized Systems and GMP, A UK Persective : Part I Background and method ; Part II
Inspection Findings ; Part III Best Practices and Topicals Issues ; Pharmaceutical Technology
International 1993
[10] S. Roman Pourquoi et comment valider un systme STP Pharma Pratiques (7) 5 332-338
1997
[11] P. ETIEVANT
Validation des systmes informatiss en environnement rglement. Stratgies et justification
conomique - STP Pharma Pratiques 4 (3), 158-163, 1994
[12] FDA. Federal Register - Part VII, 21 CFR Parts 820, 61 (195) : p. 52657.- US Dept. of
Health and Human Services, FDA, October 1996
[13] Federal register Department of Health and Human Services FDA 21 CFR part 11
current Good Manufacturing Practice Electronic Records and Electronic Signatures March
1997
[14] Bjoint H.-La signature lectronique dans lindustrie pharmaceutique. Rapport dune
commission SFSTP.- STP Pharma Prat., 10 382-389, 2000
[15] C. Jambart
LAssurance Qualit, les normes ISO 9000 en pratique- Edition Economica 1997, 2me dition
Paris
[16] T. Largeron et G Toly Validation des systmes informatiss Lapproche et les GAMP
STP Pharma pratiques 7 (5) 366-367 1997
[17] Singer K., Greene J. Note for guidance : GMP for Medecinal Products Computerized
Systems.-CSV Contents, Hoffmann la Roche Ltd., 1996
[18] Comit europen de normalisation (CEN). - lignes directrices pour lapplication iso
9001 au dveloppement la mise disposition et la maintenance du logiciel. - Normes pour
la gestion de la qualit et l'assurance de la qualit (ISO 9000-3:1991). CEN 1993, Rf. n EN
29000-3: 1993 F, pp. 365-87.
88

[19] FDA. - General Principles of Software Validation. Draft Guidance, Version 1.1. - US
Department of Health and Human Services, FDA, June 1997.
[20] M. Formet. Commission SFSTP Mise en uvre des tests de validation dun systme
informatis STP Pharma 11 (5) 255-261 2001
[21] Guide dutilisation Exascan

DOCUMENT ELECTRONIQUE
[22] www.fda.gov
[23] www.dg3.eudra.org
[24] www.ich.org
[25] www.ispe.org
[26] www.agmed.sante.gouv.fr

89

GLOSSAIRE

AFSSAPS Agence Franaise de la Scurit Sanitaire des Produits de

Sant
AMM
Autorisation de Mise sur le March
AQ
Assurance Qualit
ARI
Analyse de Risque
BPF
Bonne Pratique de Fabrication
CdC
Cahier des Charges
CFR
Code of Federal Regulation
cGMP
current Good Manufacturing Practices
CSV
Computerized System Validation
DQ/CdQ Dpartement Qualit / Contrle de la Qualit
ERP
Enterprise Ressource Planning
FAT
Factory Acceptance Test
FDA
Food and Drug Administration
FS
Fonctionnal Specification
GAMP
Good Automated Manufacturing Practices
GMP
Good Manufacturing Practices
ICH
Confrence Internationale d'Harmonisation
LDP
Ligne Directrice Particulire
LIMS
Laboratory Information Management System
PQP
Plan Qualit Projet
QC&QD Qualificationde Conception et de Design
QI
Qualification d'Installation
QO
Qualification Oprationnelle
QP
Qualification de Performance
SAT
Site Acceptance Test
SDS
Software Design Specification
SFSTP
Socit Franaise des Sciences et Techniques Pharmaceutiques
TU
Test Unitaire
URS
User's Requirements Spcification
VP
Plan de Validation

90